Saturday Feb 07, 2009

OpenSSO Community Day 2.0 - Munich - May 5 2009

You asked, we listened... the next OpenSSO Community Day is in Europe!

After I announced the NYC OpenSSO Community Day, one of the most frequently asked questions was "Can we do an OpenSSO community day near me?", with many requests coming from the other side of the Atlantic. So... we got together with our friends at Kuppinger Cole and are pleased to announce... OpenSSO Community Day 2.0!!!

Hosted by the European Identity Conference 2009 at the Deutsches Museum in Munich, Germany, and sponsored by Sun Microsystems, this is another opportunity for OpenSSO contributors, deployers and users to come together in an informal 'unconference' setting.

Being an unconference, the only rigid item on the agenda will be to decide at 9am on the sessions for the rest of the day. You can show up and talk about any OpenSSO-related topic you like. Maybe you have an interesting deployment, a new extension or a nagging question - sessions can be discussions as much as presentations. Now, that doesn't mean that there need be zero preparation - if you have a session in mind, go to the wiki and add it there, so folks can get an idea of the likely content ahead of time. We've already posted a few ideas.

All are welcome, attendance is free, and lunch will be provided. We'll likely adjourn to a nearby bar at the end of the day to continue the conversation

We're using meetup.com to manage the registration process - just join the OpenSSO group and RSVP!

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

Tuesday Jan 27, 2009

OpenSSO Community Day - NYC - March 17 2009

Join us for the very first OpenSSO Community Day!

Hosted by New York University at the Kimmel Center in Greenwich Village, New York, and sponsored by Sun Microsystems, this is an opportunity for OpenSSO contributors, deployers and users to come together in an informal 'unconference' setting.

Being an unconference, the only rigid item on the agenda is to decide at 9am on the sessions for the rest of the day. You can show up and talk about any OpenSSO-related topic you like. Maybe you have an interesting deployment, a new extension or a nagging question - sessions can be discussions as much as presentations. Now, that doesn't mean that there need be zero preparation - if you have a session in mind, go to the wiki and add it there, so folks can get an idea of the likely content ahead of time. We've already posted a few ideas.

All are welcome, attendance is free, and continental breakfast plus lunch will be provided. We'll likely adjourn to a nearby bar at the end of the day to continue the conversation

We're using meetup.com to manage the registration process - just join the OpenSSO group and RSVP. And don't delay - 5 of the 40 places are already gone!

Thursday Jan 22, 2009

Webinar - OpenSSO in the Clouds

I'll be reprising my OpenSSO in the Clouds presentation as part of BrightTALK's Cloud Computing Summit at 2pm next Thursday, January 29th 2009. Click here to attend and discover how OpenSSO fits into the cloud computing model.

Friday Jan 16, 2009

Enabling Virtual Federation With OpenSSO

Unveiled in OpenSSO last year, virtual federation is a technique for integrating existing ('legacy') applications with federation protocols such as SAML 2.0, allowing them to interact across enterprise boundaries. Today at Sun Developer Network's identity pages, Mike Hortobagyi, a solutions architect with Brighton Consulting (and 'horto' on the #opensso IRC channel), and Marina Sum, who must be just about the hardest working writer at SDN, give an overview of virtual federation and OpenSSO's Secure Attributes Exchange (SAE) component. This is part one of a two part series based on Mike's experiences over the past few months working with a Canadian financial services provider setting up virtual federation with a series of Canadian banks, so it's the real deal!

You might also be interested to know that each Sun Developer network article now has a discussion section - I just kicked things off for Mike and Marina's article - why don't you go read the article now and let them know what YOU think?

Thursday Jan 15, 2009

OpenSSO Enterprise: Developer.com Security Product of the Year 2009!

James posted earlier today on NetBeans sweeping Developer.com's Product of the Year awards for 2009. I went to take a look at the details, and what should I see, right at the bottom of the page, but OpenSSO Enterprise won Security Product of the Year! Fantastic recognition of the work that the OpenSSO community has put in over the last three and a half years, still ongoing, of course, but punctuated by the OpenSSO Enterprise 8.0 release in November. It's particularly gratifying to read "This year there were no close calls. Each winner won its category with a respectable margin.".

So... Congratulations to NetBeans (my IDE of choice, of course!), and also to MySQL, which won the Database Tool award with MySQL workbench... And THANK YOU to everyone who voted for OpenSSO Enterprise!

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.

OpenSSO Code_Swarm Visualization

Code_Swarm produces a compelling visualization of the commits over the lifetime of a software project, showing the ebb and flow of development. I put together a video last night showing the history of OpenSSO:

When you watch the video (embedded above in 'high quality', thanks to this tip at 'My Digital Life'), you can see how the project got off to a quiet start (in terms of commits) in mid 2005, then came alive at the very end of October 2005 with the first big code commitment. You can see the web agent code (rendered in yellow) being added in May 2006, then the federation code (purple) in November 2006. After that, it's pretty much one continuous firework show. One particularly spectacular blast is in late June 2008, when we had to make a global change to the copyright headers:

If you've worked on OpenSSO, it's fun to watch for your name appearing with your first commit - see if you can spot me ('superpat7') in March 2007...

Thanks to Rich for the tip.

Friday Jan 09, 2009

OpenSSO Tab Sweep - Jan 10 2009

First OpenSSO tab sweep of 2009, a pretty quiet week, but a few items worth reporting...

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...).

Tuesday Jan 06, 2009

OpenSSO and EJBCA: Use Case

Bruno Bonfils, aka asyd, longtime denizen of #opensso, has put together a VMware instance with OpenSSO and EJBCA. In Bruno's words:

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.

Watch for a series of articles at Sun Developer Network (feed) describing the integration in more depth; in the meantime, you can go download the instance and have a play - instructions are included...

Thursday Dec 18, 2008

Finishing 2008 with OpenSSO's Java EE Policy Agents

I mentioned part 1 of 'Protecting Applications With Jave EE Policy Agents' at the beginning of this month; this week sees part 2, with Hua Cui joining Sean and Marina to give more detail on how to deploy OpenSSO's Java EE Policy Agents for single sign-on within a single DNS domain, configuring several sample Java EE Web applications and having OpenSSO provide single sign-on between them.

And, with that, I'm taking a break until 2009. It's been an amazing year for OpenSSO - we shipped our first Express release in July, and our first fully supported commercial release, OpenSSO Enterprise 8.0, in November. We've seen integrations with systems from ActivIdentity 4TRESS to YubiKey (YubiKey was the closest I could get to 'Z' ) and deployments from ACA/Telenet to Yota. Dang it! Isn't there anything OpenSSO-related that begins with 'Z'?

Meanwhile, on the community side, the number of registered project members has risen from about 550 at the start of 2008 to over 900 today, while the monthly traffic on the OpenSSO Users mailing list has gone up from around 200 messages a month to nearly a thousand. Even the IRC channel is buzzing now, with contributors from Minsk to Shanghai talking OpenSSO around the clock. If you haven't yet dipped your toes in the OpenSSO water, perhaps now's the time to get started?

Tuesday Dec 16, 2008

ようこそ、 NRI!

From Japan, news that Nomura Research Institute (NRI), a consulting and IT solution services company spun off from Nomura Securities, are offering support and services for OpenSSO [Japanese press release] [Google translation to English], including OpenID for cross-enterprise authentication.

As well as being a big endorsement for OpenSSO, this event marks its graduation as an open source project - it's definitely no longer 'just a Sun thing'.

Welcome, NRI! We look forward to your contributions to OpenSSO!

Friday Dec 12, 2008

OpenSSO Tab Sweep - Dec 12 2008

It's been a while since the last tab sweep - lots of news since then, such as the OpenSSO Enterprise 8.0 release, that's kept me busy both here on the blog and 'in real life' (if there is such a thing any more!). Anyway, here are some of the titbits I've been saving for a tab sweep blog post:

Well - that wraps things up for this week. Don't forget to vote for OpenSSO in the SOA World Readers' Choice Awards!!!

Thursday Dec 11, 2008

SOA World Readers' Choice Awards - we NEED your vote

SOAWorld have extended the closing date for votes in their Readers' Choice Awards until the end of the year - Dec 31st. And IBM DataPower has pulled ahead of Sun Access Manager/OpenSSO, by 540 votes to 345.

So... We NEED your vote... If you haven't voted already, go now and vote for OpenSSO in the Best Security Solution category. You could also vote for GlassFish in Best App Server and NetBeans in Best IDE, but I'm calling for votes for OpenSSO!!!

PLEASE - go vote now. And tell your friends. Vote, vote, vote!!!

Monday Dec 08, 2008

OpenSSO in the Clouds

I just presented OpenSSO in the Clouds [PDF] at the December meeting of AWSome Atlanta, a technology meetup to discuss Amazon EC2, S3 and other cloud technology. John Willis, Michael Coté's co-conspirator on the Redmonk IT Management Podcast, invited me to speak here after Daniel and I did a video interview with Coté a couple of months ago. A nice bunch of folks here in Atlanta, pretty technical but very focused on the practical aspects of deployment. I promised I'd post my slides, so here they are.

This is also the point at which I'll switch off the OpenSSO Amazon EC2 instance I created in preparation for tonight's event. As I mentioned in my presentation - watch this space for further developments around OpenSSO and the cloud!

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