Wednesday Aug 19, 2009

OpenSSO, Jack Adams and me

At OSCON a few weeks ago, I spent a little time with OpenSolaris enthusiast Jack Adams (who doesn't seem to have his own page, but is often in the company of Bruno Souza and Deirdré Straughan), chatting about the basics of OpenSSO, single sign-on and federation. Luckily, it was all caught on video...

Thursday Jul 16, 2009

links for 2009-07-16

Saturday Feb 14, 2009

Federated Provisioning - Liberty to the Rescue???

I thought I'd throw my hat into the ring of the current federated provisioning discussion (Ian, Nishant, Ian again, James) ...

Looking at the contentious #2 in Nishant's post, the Liberty Alliance standardized one approach to this several years ago with ID-WSF.

To recap the scenario:

Suppose two companies, Acme and Omega enter into a federation agreement, whereby employees of Acme will be able to access a service at Omega using their Acme credentials. There are two scenarios here for federated provisioning.

[...]

Acme decides that they are not going to decide beforehand which employees are allowed to access Omegas service. Instead, a link to the service is available on Acmes intranet, and whenever a user decides to go to the service, they should be given an account. In this case, no pre-provisioning is taking place. Instead, the provisioning has to occur in real-time, when the user accesses the service via the intranet link for the very first time.

The idea here is that when Omegas federation server encounters the incoming SAML token for a new user, it would recognize that the user does not have a federated account, and send the SAML token to Omegas provisioning server. The provisioning server would create the account right then and there, and return the necessary result back to the federation server so that the federation server can proceed to grant the user access.

Now, in my Liberty-tinged version, when sending a new user to Omega, Acme includes a reference to their Employee Profile (EP) service - essentially the service's endpoint URL - in the SAML assertion. This endpoint reference serves as both a description of where to find the service and permission for Omega (when sent as part of the signed SAML assertion) to invoke that service.

On receiving the assertion, Omega send a signed request to the EP service, the request containing the SAML assertion it just received. Now, the EP service knows that Omega is entitled to access that employee's data, since it has a signed SAML assertion, issued by Acme itself, that says exactly that (via the presence of the EP endpoint reference). The EP can return exactly the data required (this will have been configured according to the underlying contract between Acme and Omega).

Finally, if desired, the EP can leave a marker in the employee's account that says 'account provisioned at Omega', so that Acme doesn't send the EP reference in every SAML assertion. Alternatively, Acme could deliberately send the EP reference every time. Or even reset the marker when the employee's account changes in a significant way (say, her purchasing limit is changed) so Omega can fetch the new employee data.

In scenarios where manual intervention is required on the Acme side, the EP service can return a response that says "Come back later", and the Omega service relay that to the user.

Of course, de-provisioning is a different kettle of fish, but the advantage of federated access to services is that, once the employee is gone from the Acme end, he has no way to access the Omega service anyway, so de-provisioning is a little less urgent than if the employee was logging in to Omega directly.

Like I said, ID-WSF has been around for years. Perhaps it hasn't had much adoption because businesses weren't encountering the problems that it solves. Seems like that might change now...

Saturday Jan 31, 2009

Secure Federated Identity Deployments

Nothing if not provocative, James McGovern continues our discussion on security and federation with Insecure Federated Identity Deployments. As always, James raises a number of good questions; I'll see how may I can get through here...

Does anyone know in typical deployments who has the responsibility of generating these identifiers (IDP or RP)? Do IdM products such as Sun's IdM, Oracle OIM, Courion, OpenIAM, Keychain, etc have a secure way built in to generate identifiers and pass them to third parties? Should they be exchanged via SPML, some other open standard or is this intentionally left undefined?

In a typical deployment, the IdP will generate the identifier. OpenSSO uses the nextBytes method of Java's SecureRandom class to generate 21 random bytes, which it then base 64 encodes into a String. SecureRandom provides a cryptographically strong pseudo-random number generator (PRNG), minimally complying with FIPS 140-2, Security Requirements for Cryptographic Modules [PDF], section 4.9.2 and RFC 1750: Randomness Recommendations for Security. That should be secure enough...

The persistent name ID can be transmitted to the SP in one of two ways, which I'll term interactive or batch. Interactive mode tends to be used when the user already has an account, with login credentials, at the SP, and there may not be an easy correlation possible between the user's accounts at IdP and SP. In the interactive mode, the first time the user attempts single sign-on between a given IdP-SP pair, the IdP authenticates the user, then generates a persistent name ID and sends it to the SP in a SAML assertion. The SP will attempt to locate the corresponding user in its store, and, failing to do so, will authenticate the user itself, in the same way as it did pre-SSO. On authenticating the user, the SP can write the persistent name ID into the user's profile and use it in future.

In contrast, batch mode can be used when either an automatic correlation is possible between IdP and SP accounts - the IdP and SP share some index attribute(s) that uniquely identifies the user - or when the SP has no pre-existing accounts. In the batch mode, the IdP generates a persistent name ID for each user, and writes that name ID and some collection of attributes to a file. The file is transmitted to the SP out of band, and the SP loads the persistent name ID's into its user store, either looking up existing accounts via the index attribute(s) or creating new accounts.

OpenSSO does this duty in the Sun world, although you could easily customize Sun IdM to do this - OpenSSO's createNameIdentifier() method is 21 lines of open source code, with no dependencies except java.security.SecureRandom and a Base64 encoder.

You could certainly use SPML to transmit the name ID from the IdP to the SP, since the name ID is just a fragment of XML that can travel in a SPML <data> element:


<spml:data>
    <saml:NameID 
      NameQualifier="http://saml.exampleidp.com/opensso" 
      SPNameQualifier="http://saml.examplesp.com/fedlet" 
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        YgolvKBPsL4ABSrdOpilovLnVq+X
    </saml:NameID>
</spml:data>

James goes on:

Let's say that I have an application already protected by CA Siteminder, Oracle CoreID, Yale CAS, etc and I want to use OpenSSO strictly for its federation capabilities. How should OpenSSO pass authentication context to these web access management products and what APIs would it use?

As a concrete example, let's look at the case where OpenSSO performs SP federation duties for CA SiteMinder, a documented and supported configuration, by the way, in use at several customers who balked at the cost of adding CA's federation capability. As I mentioned last time, setting an attribute in the SSO session, to indicate that the user had authenticated via federation, would work to pass authentication context from OpenSSO to SiteMinder or a similar product. Policy on the SiteMinder side would then act on the value of that attribute. Since I'm not an expert in SiteMinder integration, and CA don't publish the SDK documentation on the web, I couldn't tell you the API to use, but setting an attribute in an SSO session is pretty basic stuff. It will be there somewhere.

When people are learning a new technology, they tend to keep it simple and develop suboptimal habits. I recently did an exercise to see if past books I have written had examples of OWASP vulnerabilities and found several. To think that folks have learned to program high quality but otherwise potentially insecurely from my writings is troubling. So, what is the call to action to prevent this same thing from happening in the world of federation? Are vendors keeping it too simple? If you were to search the documentation for RSA, PingIdentity, Oracle, etc do you think they cover the aspects you outlined? Does Sun become a member of OWASP to have someone analyze the insecure aspects of federation help?

Liberty and OASIS are already the venues for this work - see the SAML 2.0 Security and Privacy Considerations [PDF] document and the Static Conformance Requirements and Testing Procedures. Note, in particular, Test Case P, 'Error Testing', in the Liberty Interoperability Testing Procedures for SAML 2.0 [PDF] - you'll see that error modes are explicitly tested. Note also that this is an evolving document, with the current version being the fourth iteration since the first was released in 2005. I'm not sure what value OWASP would add.

Wouldn't segregating local and federated users into different domains require deploying additional unnecessary infrastructure? If the RP gets its profile by reading a UID value in a cookie and then binding to a directory service, wouldn't this require changing the security model of the application which begs the question of how enterprise applications need to change to support federation. For the most part, this is undocumented and never discussed in the blogosphere Is this a use-case for leveraging XACML?

OK - that was thinking aloud on my part. You either have two user populations (outsiders and insiders), typically already identified as such in your user store (if you can't tell employees from customers, you're in a bad way!) or you have a single user population that can access the deployment via alternate methods, depending on where they happen to be. In the latter case, policy might dictate, for example, that the payroll app could not be accessed via federated SSO, enforced by the policy agent deployed into the app's container. No changes to the payroll app required. I'm not sure where XACML comes into the picture.

James goes on to ask a number of additional questions:

1. If a federated identity product is deployed as a separate tier from an application and the IDP when sending an assertion needs to not only send values that may be stored in a directory (e.g. OpenDS, OpenLDAP, etc) but also include values that may be calculated by the application at runtime, how would this work? What APIs would be used and more importantly what APIs should exist but are missing?

In OpenSSO's case, you simply implement the IDPAttributeMapper SPI, calculate the attribute values, and OpenSSO will include them in the Assertion.

2. SAML 2.0 identifiers is a great concept and Pat shows how OpenSSO can leverage them. I am curious though when they are stored in a directory service such as OpenDS, should they have a standard IETF OID for holding this attribute/objectClass?

Good question. I'm not sure they really need it, since this is an implementation detail for the federation product, rather than an interoperability point.

3. I haven't looked in detail, but the SAML 2.0 identifier outlined feels the same as the PPID leveraged in Cardspace. If they are different, then did Microsoft violate some principle? If they are the same, then shouldn't there be a standard as to how this is represented as MS will generate it differently than Sun? What other "best practices" exist around generating this value?

The semantics aren't quite the same. The PPID is associated with a card at the IdP, in the context of a specific relying party, while the persistent name ID is associated with the user account at the IdP, in the context of a specific service provider. Having said that, for managed cards, I think they are equivalent. SAML 2.0 says this about the persistent name ID:

Persistent name identifiers generated by identity providers MUST be constructed using pseudo-random values that have no discernible correspondence with the subject's actual identifier (for example, username). The intent is to create a non-public, pair-wise pseudonym to prevent the discovery of the subject's identity or activities. Persistent name identifier values MUST NOT exceed a length of 256 characters.

The relevant spec in the CardSpace, um, space, is the Identity Selector Interoperability Profile V1.5, which gives various mechanisms for constructing PPID's, each of which results in a Base64 encoded SHA256 hash, resulting in a 44 character string, which is well within SAML's 256 character limit. So it's certainly possible for a user's persistent name ID to be the same as the PPID for the same IdP/SP pair.

4. Did Gerry Gebel of the Burton Group test out these scenarios at the Catalyst conference?

I don't think there was an interop demo at Catalyst 2008, but at the Concordia interop demos at RSA, we tested a CardSpace/SAML interop scenario, passing an authentication context URI to indicate to the SAML SP that the user had authenticated via some CardSpace mechanism (self-issued card, managed card with password authentication to the IdP, etc). Given the scope of both PPID and persistent name ID, it wouldn't make sense to pass them across the CardSpace/SAML 2.0 boundary, since there are two discrete IdP/SP pairs at work here.

You could imagine a scenario where users could use either CardSpace or SAML 2.0 between a given IdP/SP pair, using the same PPID/persistent name ID value. I can't see any problem here, since, as I describe above, SAML 2.0 does not define any particular structure or semantics for the persistent name ID beyond a maximum length, which the PPID satisfies.

5. Recently, I had the opportunity to hang out with some folks from Voltage who discussed the concept of identity based encryption (IBE). Should federations support IBE in addition to traditional PKI approaches?

The PKI in federations is point-to-point between providers, certificates being the trust anchor for signed metadata, which in turn contains message signing certificates. Typically, IdP's and SP's either exchange certificates out-of-band in a pairwise manner, or there is some trusted authority that signs metadata for a whole population of providers. You could conceive of a mechanism that would use IBE to generate keys from SAML 2.0 entity identifiers (which are simply URI's), with a Private Key Generator (PKG) from which the providers retrieve their private keys. The issue I see here is well documented - the PKG has access to ALL of the private keys in the PKI. This might be OK for inter-department federations within a larger organization, but I can't see it flying for inter-enterprise federation. I can't see any particular advantage in the former case, either. If you trust some central authority to issue private keys for a population of providers, you might as well trust it to distribute a signed metadata file.

6. Does Sun have any plans on making the J2EE Petstore OpenID and federation-enabled?

No. I think the stumbling block here would be that there is no Java EE API for federation, so any such enabling would be OpenSSO-specific, which kind of goes against the point of the Petstore in demonstrating Java EE. Of course, we could show how to use OpenSSO with the Petstore, but this wouldn't quite be the same.

Phew! That was a long, detailed post! Hopefully there's some useful stuff there. Some of it might even be accurate

Thursday Jan 15, 2009

Webinar - Access Management, Federation, and Secure Web Services with OpenSSO Enterprise

The (unfortunately) irrepressible Daniel Raskin and his sometime co-conspirator Jamie Nelson are presenting a webinar on Access Management, Federation, and Secure Web Services with OpenSSO Enterprise next Wednesday, January 21. Unfortunately, this will be a 'regular' webinar (no Second Life acrobatics this time!), but tune in anyway for all the latest on OpenSSO Enterprise.

Monday Jan 12, 2009

Did You Know That Federated Identity Deployments Are More Secure Than You Think?

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 someone@creditsuisse.com. 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.

Wednesday Nov 12, 2008

Federated Single Sign-On for Google Apps in OpenSSO

Hot on the heels of the OpenSSO Enterprise 8.0 release comes Wajih Ahmed and Marina Sum's article on configuring Federated Single Sign-On for Google Apps in OpenSSO. With just a few minutes of work, you can be authenticating users in OpenSSO and giving them access to their accounts in Google Apps, including Google Mail, Google Documents and Google Calendar. Take a look at the demo we recorded with Michael Coté a few weeks ago to see the end result.

While this integration has been possible ever since we introduced SAML 2.0 support in Access Manager, it used to require a small amount of custom code to copy the user id into the SAML 2.0 NameID element. With OpenSSO Enterprise 8.0, it's now a simple matter of configuration in the administration console.

To illustrate the article, Wajih has captured the configuration process on video - settle back and enjoy the show.

Thursday Oct 16, 2008

links for 2008-10-16

Wednesday Oct 01, 2008

links for 2008-10-01

Tuesday Sep 30, 2008

links for 2008-09-30

Friday Sep 26, 2008

links for 2008-09-26

Tuesday Jun 03, 2008

From the Trenches - Virtual Federation: a Pioneering Way for Exchanging Authentication

The Sun Developer Network's Marina Sum spent some time recently talking to my fellow Federated Access Manager architect Rajeev Angal about Virtual Federation, a new feature forthcoming in Sun Federated Access Manager 8.0 (but available now, of course, in OpenSSO). Virtual Federation promises to simplify federation by allowing legacy applications to interact across enterprise boundaries via a SAML 'tunnel'.

Read the interview for an overview of Virtual Federation; this article has the gory details under the old name 'Secure Attribute Exchange'.

Thursday Mar 20, 2008

links for 2008-03-20

Friday Mar 07, 2008

Federated Identity Through the Eyes of the Deployer

As I just reported over at The Aquarium, Eve and Marina recently published Federated Identity Through the Eyes of the Deployer - what it is, why you might want it and what questions to ask as you architect a federated identity system.

As I mentioned on The Aquarium, Eve was a key player in defining XML, SAML and more. What you might not know is that Eve is also a talented musician, shining even when accompanied by those less gifted in the art, such as here, at IIW2006b:

Here be the lyrics.

Monday Mar 03, 2008

Burton Group Tech Watch podcast: Adoption and State of the Federation Market

Gerry Gebel of The Burton Group kindly invited me to participate in their most recent podcast, on the topic 'Adoption and State of the Federation Market', along with Patrick Harding of Ping Identity and David Miller of Covisint. Do Patrick and I come to (verbal) blows? Listen in and find out! [MP3]

About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today