This just in:

Ex-Fannie Mae worker charged with planting computer virus

By Freeman Klopott
Examiner Staff Writer 1/29/09

A fired Fannie Mae contract employee allegedly placed a virus in the mortgage giant’s software that could have shut the company down for at least a week and caused millions of dollars in damage, prosecutors say.

Rajendrasinh Makwana, an Indian citizen, was indicted Tuesday on computer intrusion charges. The former Gaithersburg resident is out on $100,000 bail, court documents said.

Makwana was fired from his contract position at Fannie Mae on Oct. 24 for changing computer settings without permission from his supervisor…

Note: he was fired for changing settings without permission. The system, it appears, had no built-in mechanisms for defining permissions and limiting actions accordingly. But if they catch someone doing it, they'll fire him. Feel safe?

Or would everyone sleep better if the data were in the professional custody of a cloud service provider, with rigorous definition of roles and abilities? And with robust, in-depth data protection technologies and practices?

Bottom line: compared to most people's Mission:Impossible imaginings of Black Hat Hacking, the real-world security of most data has less to do with where it's stored and much more dependence on the mechanisms in place for limiting privileges and blocking destructive behaviors.

Disciples of the on-premise myth of "control of your own IT" are urged to pause and reflect.

There's been some recent discussion on SXIP's decision to build hardware to support Salesforce.com's delegated authentication protocol.  Delegated authentication is a process where Salesforce makes a secure web services call to an endpoint that a customer defines.  Salesforce can delegate authentication to the customer, which can allow for building web single sign on, integration with two-factor, integration with an LDAP directory, and many other possibilities.

What hasn't been discussed is why Salesforce is using a delegated authentication scheme, rather than just accepting SAML tokens.  So why'd we do it?

Supporting SAML on our website would have been easy.  But we have a huge amount of our traffic that doesn't come to our website, but to our Sforce web service APIs. 

We have an outlook plugin, a plugin for word and excel (office edition), an offline edition, and a wireless edition.  We also have many partners who have build products on top of our APIs.  An example we like to use is access Salesforce on a Blackberry.  We have a number of partners who have successful products to allow customers to access Salesforce on a Blackberry.

How do the clients, which all use web services to authenticate (using login and password today calling our login call), know where to get the SAML token from, in a standard way?  There is no standard way to do this today, and even standards like WS-Trust don't seem to solve this problem.  For example, you build a client using our web services apis.  You deploy to all our customers.  Customer A has one SAML provider.  Customer B has another SAML provider.  How does your code know where to go to get the token when deployed at customer A and at customer B, without configuring all of the clients with the location of the SAML provider? 

We suggest customers can use web single sign on, and a shared password for the clients.  So when I login through the web, a SAML token can be passed through.   When I use the web services-based clients, I use my Active Directory password.  This is a simple solution

For our customers, a hardware based solution is a no-brainer.  It's simpler to deploy, and less to maintain on their end.

We'd love to hear how others are thinking about solving the web + web services authentication problem, when there can be an unlimited number of clients that need to authenticate against your service.

Interesting comments from Craig Burton, Kim Cameron & Marc Canter on the Sxip identity appliance (which supports delegated authentication and Single Sign On for salesforce.com), and the follow up from Sxip. I think it totally makes sense to offer this as an appliance, that's one less server for your overworked and under resourced IT department to have to manage.

Some users get tripped up because their organization has a security policy to cause users to reset their passwords every X days.   After 60 days of the integration working, it fails, because the user got locked out of their account!

If you have an integration user, you have a few options

Your first option is to change your password programmatically when it expires.  LoginResult will come back with the PasswordExpired flag = true, and returns a sessionId that is only good to use the setPassword call.

Another option is a flag on the profile to allow passwords to never expire, called Password Never Expires.

If you plan to enable password never expires we recommend you also lock down access for this integration user by IP ranges.  Use the IP range restriction feature on profiles.

Note that if your organization does not have a security policy to reset passwords every X days, this will not be a problem for you.