Instructions for building s3fs for OpenSolaris so you can mount an S3 bucket as a file system. Nice!
James McGovern asks the rhetorical question “Did you know that many federated identity deployments are insecure?”. I’ll leave James’ criticisms of OpenID and Cardspace to the respective experts, as I’m really only on the periphery of those communities, but let’s have a look at the insecurities he perceives in SAML-based federation…
James’ main point on federation is:
Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store […] So, if salesforce.com is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. Salesforce.com would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along?
There are multiple layers of protection against this kind of attack. The most obvious mitigation is the use of SAML 2.0 persistent identifiers. A persistent identifier is an opaque string (in practice, a long random sequence of characters, such as ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M that is shared by exactly one identity provider and one service provider to identify a given user. Now, let’s assume that our rogue Goldman Sachs employee manages to discover the persistent identifier of a Credit Suisse employee (difficult, since this value would only be shared between Salesforce.com and Credit Suisse). On receiving a SAML assertion from Goldman Sachs, Salesforce.com would look the user up with (Goldman Sachs, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), which would not match (Credit Suisse, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), so the assertion would be rejected. You can check out the OpenSSO source code to see how this works – persistent IDs are scoped to the (identity provider, service provider) pair, so you MUST use the identity provider when resolving them, since there is no guarantee that two identity providers won’t accidentally (or otherwise!) generate the same ID.
Can our rogue Goldman Sachs employee hack around with the assertion, to try to fool Salesforce.com and get access to the Credit Suisse data? Well… he can try… Even forging every field in the assertion, without the Credit Suisse signing key, he cannot impersonate a Credit Suisse employee, since, ultimately, the signing certificate will not match that on file for Credit Suisse. Of course, it’s possible for an implementation bug to subvert all this careful specification work, as we saw with the Google/SAML vulnerability discovered last year.
Now, anyone familiar with Salesforce.com’s implementation will be quick to point out that they don’t in fact use SAML 2.0 persistent ID’s, instead giving you the option of ‘Federation ID’ or Salesforce username. The former is an arbitrary string that the admin can set in the user entry at Salesforce.com, so you could use this in the same way as a SAML 2.0 persistent ID. Let’s focus on the latter – Salesforce username, which is often, in fact, the user’s email address – James’ use case!
Now, let’s imagine our rogue Goldman hacker has set his email address to firstname.lastname@example.org. Well, the remainder of the assertion has Goldman Sachs all over it, so, assuming Salesforce.com are using the assertion issuer name when they look up the email address, our hacker is still denied entry. And remember, we can’t forge the issuer name, since that will provoke a mismatch on the certificate. I clearly can’t see inside Salesforce.com’s SAML implementation to check that they do match on the assertion issuer, but I can tell you that OpenSSO does exactly this. Again, SAML provides the framework to federate safely, but it’s down to you, the implementer, to get it right. And you can improve your chances of doing so by using an off-the-shelf implementation rather than rolling your own.
James’ other point on federation:
[…] federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn’t even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.
Speaking for OpenSSO, we do not separate federation and web access management. You can assign an authentication level to SAML federation and use that in policy. Perhaps ‘level 1’ is SAML, ‘level 2’ is local username/password and ‘level 3’ is a hardware token; the ‘order entry’ app might specify level 2, while the ‘payroll’ app would specify that level 3 authentication is required. There are other ways of implementing this that spring to mind; segregating local and federated users into different domains for example, or testing some attribute in the user profile.
All good points from James, I have to say, illustrating the fact that, even if your wire protocol is secure, implementation issues can easily lead to vulnerabilities.
First OpenSSO tab sweep of 2009, a pretty quiet week, but a few items worth reporting…
- We started the week with a bang – 400,000 ‘jarheads’ will be using Sun’s identity suite to access both classified and unclassified networks – Sun and BearingPoint will be providing identity and access management solutions (including Sun OpenSSO Enterprise) to the United States Marine Corps. We’ll be doing our utmost to avoid pissing off that particular group of end-users!
- Meanwhile, over at the Sun Developer Network, Marina (does she ever sleep?) Sum and the OpenDS QA team’s Gary Williams bring us Perspectives on Quality Assurance for OpenDS, offering some fascinating insights into the tools and techniques used in OpenDS quality assurance. As you might know, OpenSSO uses OpenDS as its embedded configuration store; we’ll be adding the capability to use OpenDS as an external user store (an alternative to the currently supported Sun Directory Server and Microsoft Active Directory) in the next release.
- Finally, if you thought that Googling opensso hamster would garner zero hits, you’d be wrong… SecuGen‘s Hamster Plus and Hamster IV fingerprint biometric readers are now compatible with Sun Solaris, Sun Ray, and Sun’s Identity Management Solutions, including OpenSSO, which is nice.
Ah well – at least there are no hits for opensso potoroo… Yet… (Yes, it took me many many tries to find an animal that generated zero hits on Google when combined with OpenSSO. A potoroo is an Australian marsupial – much like a bandicoot. In case you’re wondering, there are 28 hits for opensso bandicoot. What a strange world we live in…).
Tweaks to speed up Firefox. Saving it here so I can undo them if anything untoward happens!
The future of commercial open source software lies in commercial licensing strategies, but which are the strategies that are more likely to deliver the results vendors are looking for?
As more open source vendors adopt an "open core" business model, will you pay for proprietary extensions and advanced features?
The image was made to demonstrate an application protected by opensso. The application is divided in three parts, the first one is available for everyone (non authenticated users). The second part, the secure area, is available only for users authenticated in OpenSSO, and members of group employee. And finally, only users authenticated by certificates and member of group employee can access to the very secure area.