Friday Mar 27, 2009

OpenSSO Tab Sweep - Mar 27 2009

As always, a bumper crop of OpenSSO news from the last couple of weeks...

That wraps things up for another week - I'm off to jump in the Patmobile and brave 101. See you next time!

Wednesday Mar 25, 2009

Jobs @ OpenSSO - March 2009

Sun is hiring engineers for OpenSSO and related identity products - we have a number of positions spanning engineering, QA and UI design. If you read my blog regularly, you'll know that OpenSSO is hot stuff - open source single sign-on, federation and secure Web services, delivered as Sun OpenSSO Enterprise and used in deployments large and small.

BTW, we have a referral bonus scheme at Sun, so, please, if you do apply for any of these positions, list me (Pat Patterson, <script type="text/javascript" language="javascript"> </script>) as the referrer - I'll buy you lunch once you start

UPDATE - I added another position and updated the publication time... We may have more reqs in the pipeline, so watch this space...

  • Entry Level Engineer (0-2 yrs experience) - we're looking for junior folks with some experience in Java, C++, J2EE, XML, servlets, and web technology development. Any middleware experience would be a bonus.
  • Senior Quality Engineer (6+ yrs experience) - a rare opportunity to get into one of the best QA teams in the business - OpenSSO QA team manager Indira Thangasamy talks about what's involved.
  • Interaction Designer / Information Architect (0-2 yrs experience) - anyone seeing the evolution of Access Manager into OpenSSO over the past few years will have seen our emphasis on ease of use and UI design. We're not done yet, though! We need another UI designer to work on projects across the identity management product line.
  • Senior Java-based User Interface Developer (3+ yrs experience) - JSF, RIA, Ajax - buzzword heaven in this UI developer post. The job spec currently says 'Identity Server project management', but it looks like that's a typo for 'Identity Manager' - OpenSSO's provisioning cousin. Unlike the other jobs, which are all Bay Area-based, this one is 'Any US Sun Location' - a great opportunity if you have wicked Java Web UI skills but are based in Colorado, or Massachusetts, or Texas, or...

If those links are no longer by the time you're reading this, then you can use these search links for OpenSSO jobs at Sun and identity-related jobs at Sun.

Thursday Mar 19, 2009

A Grand OpenSSO Community Day Out in New York

Many thanks to all who attended (I counted at least 50) and spoke at our very first OpenSSO Community Day this past Tuesday in New York City, and to NYU for making available such an excellent facility.

We had a range of speakers: some from the OpenSSO product team, some from other parts of Sun, and even one SI partner - Mike Schwartz from ID-Vault. As promised, we assembled the agenda at the start of the day, and managed to fit in nine 40 minute sessions covering pretty much every aspect of OpenSSO. Almost all the slides are online at the event wiki page (slides, please, Brad!).

If you attended the community day, please complete the Meetup survey - we'd love to have your rating and comments.

The next stop for the OpenSSO Community Day roadshow will be Munich, on May 5. Remember, if you're also planning to attend the European Identity Conference (hosts for our event), you can get 20% off your registration fee by quoting the discount code OPENSSO.

Watch this space for news of OpenSSO Community Day 3.0 - to be held in San Francisco, around the time of CommunityOne West/JavaOne.

Friday Mar 13, 2009

OpenSSO Tab Sweep - Mar 13 2009

Lots of news over the last couple of weeks from the world of OpenSSO. Events in New York, new Fedlet innovations and more; read on...

That wraps things up for this week. Don't forget, if you're planning to attend the European Identity Conference 2009 in May, the second OpenSSO Community Day will be there on the Tuesday, May 5 2009. Register at Meetup and you can pick up a discount code for 20% off the cost of your EIC registration. Bargain!

Tuesday Mar 03, 2009

Swekey Authentication Module for OpenSSO

I just finished another OpenSSO Extension - this time, an authentication module for the Swekey authentication key (README, source). The authentication module prompts the user for their username and uses the Swekey to generate a one-time password, which is validated against the Swekey authentication server.

It's interesting to contrast the Swekey with the Yubikey, which I covered here a few months ago. Where the Yubikey emulates a USB keyboard, requiring no special client software, the Swekey requires a driver. On the other hand, where the Swekey is invoked automatically by a browser plugin, requiring no user intervention apart from inserting the device into a USB port, the Yubikey requires the user to press its button and, potentially, ensure that the cursor is in the correct input field. One thing they do now have in common, though: they both work with OpenSSO

So, if you have a Swekey, grab the authentication module, deploy it (see the README) and let me know how you get on.

Friday Feb 27, 2009

OpenSSO Tab Sweep - Feb 27 2009

Wow - it's been nearly 7 weeks since the last tab sweep, not so much due to a lack of OpenSSO news, quite the reverse - so much going on that I've not had 2 minutes to sit down and document it. Anyway, here we go...

That wraps it up for February. Watch out for more exciting OpenSSO news coming soon!

Wednesday Feb 18, 2009

Verizon Wireless on Improving Security and User Experience with Sun Access Manager

Last November, at the Gartner Identity and Access Management Summit 2008 in Orlando, FL, Damo Bashyam of Verizon Wireless (VZW) gave a presentation titled 'Simplify Identity Management to Improve Security and Online Customer Experience'; Daniel just pinged me to say that this presentation is now online, along with the associated slides, and what a presentation it is!

If you're looking for marketecture, then move on; if you want to know how the largest wireless telecommunications network in the United States is using Access Manager (the old name for OpenSSO Enterprise) in a high-scale, high-availability deployment, then it's all here, in just 23 minutes. Some of the numbers are staggering: over 40,000,000 users, 1,000,000 logins per day, peaking at 4,000 logins per minute. VZW deployed Access Manager into two data centers, with session failover within each data center and multi-master replication between six Sun Directory Server instances.

The preso and slides detail all this and the business benefits to VZW - for me, given my focus on federation, one highlight was the fact that they have extended single sign-on to 25 third-party application service providers (ASPs), 12 of them in a single night with just 4 hours (planned) downtime for the cutover. Another interesting aspect is that this is a Sun stack, top-to-bottom, so VZW have just one throat to choke in the event of an issue, with no intra-vendor finger pointing. Damo describes it as a partnership - one that has brought real and lasting benefits for both partners.

So... go download the slides, make yourself a nice cup of tea, and spend a few minutes watching the preso:

Thursday Feb 12, 2009

OpenSSO Deployments Around Europe

News from Europe of some interesting OpenSSO deployments... First, in France, Capgemini has been working with Valeo, a major manufacturer of automotive components, to replace a Lotus collaborative platform with Google Apps (plus a set of custom web applications) for over 30,000 employees. If you've been keeping up with Superpatterns, you'll have guessed what they're using to provide Valeo employees with single sign-on across the whole set of web apps... Yep, OpenSSO. This French story gives some more detail [PDF].

A couple of stories came out of Norway last year on their government-to-citizen and government-to-business systems, MinID (My ID) and Altinn respectively. In April, the Norwegian Ministry of Government Administration and Reform published 'Clearing the PIN Code Chaos on Public Web Sites', describing how citizens had to manage a large number of usernames, passwords and PIN's to access Norway's various government department websites. Then in July, Accenture won the contract to implement the next generation of Altinn. The 'eID-interoperability hub' and 'advanced security solution' mentioned in the articles? You guessed it... OpenSSO.

OpenSSO - powering single sign-on and federation all around the world...

Monday Feb 09, 2009

Attend an OpenSSO Community Day, Save €€€!

As Daniel just blogged, attendees at our second OpenSSO Community Day, to be held at the Deutsches Museum in Munich on May 5 2009, can get a 20% discount off their registration for the European Identity Conference 2009, which is kindly hosting us during their conference week. Just quote OPENSSO when you register and you'll get the discount. As Daniel says "We will be passing an attendance list to Kuppinger-Cole so you need to show-up to our community day to get this discount".

Meanwhile, looking at our first OpenSSO Community Day, in New York City, on March 17 (yes, St Patrick's Day; no, that wasn't intentional - honest!) we blew past our original estimate of one man and a dog and had to move it to a bigger room. We're now in the Shorin Performance Studio on the 8th floor of the Kimmel Center.

Currently leading in the unofficial "furthest travelled attendee" contest for New York looks to be Kimimasa, flying in from Japan. Can anyone beat that? Any OpenSSO community members in Perth, Australia?

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.

Tuesday Jan 20, 2009

Desktops in the Cloud

Crack Sun identity management field operatives Paul Walker and Joachim Andres have put together an amazing demo of Sun's identity stack working with Sun xVM and Secure Global Desktop to provision (and disable!) 'Desktops in the Cloud' to end users. It's an integration tour de force, bringing together a whole slew of Sun products into a whole that is much more than the sum of its parts. Cool soundtrack too - well worth 12 minutes of your time. Oh - and make sure you view 'full screen', so you can properly see what's happening - there's quite a lot going on!

Saturday Jan 17, 2009

Identity Management Buzz TV Videos from DIDW 2008

At DIDW 2008 last September, Daniel Raskin, Nick Wooler and I, among others, recorded a series of videos covering various aspects of identity management. I just went and watched the first in the series - a fascinating discussion between Daniel and Felix Gaehtgens of Kuppinger Cole - 'Open Source in Identity'.

One thing I noticed, on looking through the series, is that the number of views varies widely between the videos - from as little as 22 to more than 4000. There's some great stuff in there, well worth watching, so here are all the videos, have a browse through and see what takes your fancy...


Open Source in Identity - Felix discusses the advantages of identity management in open source with Daniel Raskin.


Identity Bus - Felix chats with Daniel about varying industry perspectives on the identity bus and Sun's Security Token Service.


Social Networking & Identity: Platforms Power - Nick Wooler and I talk about the impact social networking has had on identity management.


Safeway's Benefits of Sun Identity Management - Paul Rarey, Chief Architect for Safeway, talks with John Barco about the benefits Sun identity management has provided to this retailer.


OpenSSO Enterprise and Sun Master Data Management Suite - Daniel talks with David Codelli from the JavaCAPS team about Sun's MDM Suite and the benefits of having a single customer view.


Identity and Access Management Deployment Best Practices - Sun's Saryu Nayyar visits with Steve Curtis of PricewaterhouseCoopers about practices for both new and existing customers.


A Discussion on Role Management with The 451 Group - 451 Group Analyst, Steve Coplan, talks with Sun's Sachin Nayyar about the Why, the What and the Where of role management.


Sun IDMBuzz Tv: Federation and OpenSSO: Connecting the Dots - Julio Tapia hosts a roundtable discussion on Federation and OpenSSO with Steve Curtis from PricewaterhouseCoopers and Daniel Raskin from Sun.


Identity and Access Management Trends and Strategy - Identity experts, John Barco and Sachin Nayyar discuss the trends and strategies in identity management.


OpenSSO and Glassfish: A Match Made in Heaven - Daniel talks with Glassfish Engineer, Doug Strickland, about synergies between identity and glassfish.


Access Certification: A Critical Identity-based Control - Listen to Sun Sr product Line managers Nick Crown and Craig McDonald discuss the importance of Access Certification and the introduction of Sun Identity Compliance Manager.


Sun IDM Buzz TV: Sun OpenSSO Enterprise - Daniel and I discuss how this solution solves three tough challenges.

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