SUN's Identity Management info Identity Fever

I've been receiving an increasing amount of questions on connecting OpenSSO with Shibboleth.

I previously wrote a blog on connecting OpenSSO in SP mode with a Shibboleth IDP using SAML2, and
have updated that article with links to more detailed information.

These are the steps to connect a Shibboleth SAML2 SP with OpenSSO in IDP mode :.

STEP 1: Create Hosted IdP Configuration in OpenSSO console (if you want to use it in production, 
make sure to have your credentials in the keystore, for proof-of-concept scenarios the keystore 
contains one test key)
STEP 2: Grab the newly created OpenSSO IdP metadata XML (you can use either ssoadm.jsp 
export entity command or access directly 
/opensso/saml2/jsp/exportmetadata.jsp?entityid=<created-entitiy-id-of-the-idp>) and reference it in 
the Shibboleth SP configuration.
STEP 3: Edit the Shibboleth SP metadata (/Shibboleth.sso/Metadata), and remove 
all the XML digital signature AND the <md:Extensions> nodes.
STEP 4: Create a Remote Service provider in the same Circle of Trust 
(ssoadm.jsp, import-entity or from console wizard)
STEP 5: Make sure you connect the IdP and SP metadata to the same Circle of Trust profile
STEP 6: Use the OpenSSO console to edit IdP metadata, and add attributes. 
All the released attributes must use the URI-style attrname-format 
(Shibboleth  won't accept unspecified attribute nameformat), so use the following syntax
urn:oasis:names:tc:SAML:2.0:attrname-format:uri|<saml-attr-name>=<local-attr-name> 
Additional information regarding Shibboleth can be found in the OpenSSO mailinglist archive. 
That's it folks. Go play !

1. Use the latest nightly OpenSSO build (or the next Stable build that will be released), you will need many fixes from the last weeks, therefore the last OpenSSO Express build is too old...
2. Create a Hosted IdP Configuration in OpenSSO console (if you want to use it in production, make sure to have your credentials in the keystore, for proof-of-concept scenarios the keystore contains one test key)
3. Grab the newly created OpenSSO IdP metadata XML (you can use either ssoadm.jsp export entity command or access directly
   /opensso/saml2/jsp/exportmetadata.jsp?entityid=) and reference it in the SP configuration.
4. Edit the Shibboleth SP metadata (/Shibboleth.sso/Metadata), and remove all the XML digital signature AND the nodes.
5. Import the modified SP metadata to OpenSSO (Via ssoadm.jsp, the import CLI or through the OpenSSO console)
6. In the OpenSSO console, add the IdP and SP metadata to one Circle of Trust profile
7. Use the OpenSSO console to edit the IdP metadata, and add attributes.

All the released attributes must use the URI-style attrname-format (Shibboleth won't accept unspecified attribute nameformat), so use
the following syntax : urn:oasis:names:tc:SAML:2.0:attrname-format:uri|=

That's it : from now on you can federate identities with the Shibboleth 2 IDP.

Should you need detailed instructions, have a look here.

There is also a lot of information available in the mailinglist archive.

Ever seen a customer ask the following ?

So how do you do it ?
There are a couple of scenario’s to do this, but one scenario may be the easiest :

1. Deploy OpenSSO
   


2. Protect OpenSSO as you would protect any web application with the old SSO solution. (this can be done by an agent, proxy, or any other way it was done in the past)
   
   
3. In OpenSSO, create and deploy a zero-page custom authentication module. This is a very simple authentication class getting the userid from the HTTP header, allowing  the userID to be used later by OpenSSO when starting the session. At this point, there is no need to verify the password, as that was already done inside the old SSO environment.
   

• Applications still connected to the old SSO environment will be authenticated the old-fashioned way.
  
  
  If however the end-user moves to an already migrated application, that application will request the identity from OpenSSO.  As there will be no session inside OpenSSO yet, OpenSSO will start it's own authentication via the above described zero-page fashion, (thus by receiving the userid from the old SSO solution - received when OpenSSO redirects forward and back to the old SSO solution when handling its own protection)
• In the event a user starts with an already migrated application, he/she will be redirected to OpenSSO for authentication. As OpenSSO is protected by the old SSO solution, authentication will be required inside the old SSO solution meaning that the user is redirected once again to the old SSO solution. Once authenticated there, the user will be redirected back to OpenSSO, the userid will be used for the session (via f.e. the HTTP header), and the application will be given the correct userid by OpenSSO. The end-user can now freely move to application not migrated yet, as the session already exists in the old SSO solution.
  

Therefore, the experience for the end-user is full SSO between migrated and not-migrated applications.

When the migration is completed, OpenSSO can be configured again not to be protected by the old SSO solution, and the new authentication modules can be activated replacing the zero-page authentication module.
That way, all migrated applications will be served by OpenSSO and the old SSO solution can be removed.

I came across a question regarding Sharepoint and SAML1.1.
A partner wanted to connect Microsoft Sharepoint with a SAML 1.1 Identity Provider (in this case the Belgian Federal Authentication Service - FAS).
The main problem is that Sharepoint does not speak SAML 1.1, nor does the Windows platform it is running on.

The solution via Sun's OpenSSO is simple as it supports loads of federation protocols !

1. First setup SAML 1 single sign-on between the SAML 1 IDP and OpenSSO as SAML1 SP


2. Then setup WS-Federation SSO between OpenSSO as an IDP and Microsoft Sharepoint as a Service Provider (SP)


3. Initiate SAML 1 SSO from the SAML 1 IDP with final redirect URL set to the  OpenSSO WS-Federation SSO initialization point  (for example http://://WSFederationServlet/metaAlias/?goto= )


4. In this case, SAML 1 IDP will start an IDP initiated SSO and post the Assertion to the OpenSSO  server instance


5. The OpenSSO server will then process the SAML1 protocol accordingly, and  redirect to WS-Federation SSO initiation URL


6. After completion, OpenSSO will then  start WS-Federation protocol and send the assertion to Microsoft Sharepoint to complete  WS-Federation protocol.
   

One thing to note - Sharepoint will need an 'SP' instance of AD-FS to communicate with OpenSSO as Sharepoint itself does not speak WS-Federation.

So - the protocol connection would look like :
SAML 1 IdP -- SAML1 --> OpenSSO -- WS-Fed  --> AD-FS --> Sharepoint 

Thank you Pat Patterson and Qingwen Cheng for helping me solve the question.

A similar use-case using SAML2 in stead of SAML1 is even more easy, thanks to OpenSSO's multi-federation Protocol Hub.

In the world of federation, there are a few standards available to allow human2application single sign-on.  The open standards include SAML2 and ID-FF (now part of SAML2), and Microsoft's WS-Federation. 
As SAML2 and WS-Federation are mutually incompatible, it has been a challenge to connect WS-Federation platforms with those supporting SAML2.

Fortunately, Microsoft recently announced last few weeks that their new Server platform "Geneva" will be supporting SAML2 as a federation platform.  This basically means that Geneva servers can start playing a role as IDP or SP in a federated environment.   Combinations of .NET platform federating with an OpenSSO via SAML2 will become easy, the vice versa should also be possible. 

Good Job Microsoft on embracing the Open Standard SAML2 !!!  I'm looking forward to future circles of trust that will be created as a result of this.

More information : http://www.kuppingercole.com/articles/fg_micro_gen_271008