Saturday Jan 30, 2010

Belgian Edition European Usergroup OpenSSO Community

As communicated earlier, the OpenSSO community has annouced OpenSSO Express 9.  See new features details here.

This release will be the main topic on the next Belgian edition of the European OpenSSO Userdays.
The event is organized by ACA IT-Solutions together with Community Builder.

Time and place :
February 10th, from 8:30 AM till 12 PM
at Sun Microsystems Belgium Lozenberg 15, 1932 Zaventem

The agenda includes presentations by four internationally recognized OpenSSO experts: Alan Foster, Jonathan Scudder, Steve Ferris and Victor Ake.
The program includes “What’s new in OpenSSO Express 9, “Monitoring”, “Entitlements Service”, “Secure API authorization” and “Fedlet”. More information is available at

Participation is free. For registration, please contact Rikke Holten:

Tuesday Nov 10, 2009

Connect OpenSSO as a Shibboleth 2 IDP to a Shibboleth SP using SAML2

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 !

Thursday Feb 26, 2009

Improved SPRING 2 support for OpenSSO

For a long time already, through the OpenSSO Extensions incubator, we have provided support for Spring Security (Acegi) and Spring Security 2.
Support for Spring Security 2 was just improved upon, by adding the ability to use Sprint security JSP tags, method security annotations and Sprint method security point cuts.

Interested ? Learn more here :

Tuesday Feb 03, 2009

Create your own custom authentication module for OpenSSO

Many times, one starts using opensso but needs a custom way to do authentication.
For instance, the authentication method is only exposed through a webservice, you need 2 passwords in stead of one, ...

I stumbled upon a blog entry explaining exactly what you need to do to write a custom module, and how to register it with OpenSSO.
You can find the article right here :

Friday Jan 30, 2009

OpenSSO webcast going into the functionality of OpenSSO Enterprise

On january 21th 2009, SUN Microsystems hosted a webcast on OpenSSO Enterprise.
The webcast takes about one hour, and dicusses both general and advanced technical topics of this exciting product.
Those that are interested in roadmap information and future-to-be functionality ready to be added in 2009 will find this webcast very interesting.

Additional technical information can be found at :
The commercial product page is located at :

Saturday Dec 20, 2008

Federating OpenSSO with .NET service providers via a Fedlet

If you have been reading my blogs on OpenSSO lately, there is a red line through all of them.
OpenSSO is breaking down technology walls, allowing connectivity from OpenSSO with a larger growing set of back-end technologies.

I just discussed OpenSSO's ability in federating with Shibboleth via SAML1 and via SAML2 (something that seemed impossible before).

As we are speaking, the next  step is in the making, allowing OpenSSO to install a fedlet on a .NET environment, allowing that .NET environment to take the role of a Service Provider(SP), and consume identities authenticated by OpenSSO in the IDP Role.

Please have a look at the following Blog entry by Rajeev Angal about the .NET Fedlet (prototype)
Keep watching the evolutions on for this feature to appear.

Thursday Dec 18, 2008

Connect OpenSSO as a Shibboleth 2 SP to a Shibboleth 2 IDP using SAML2

Using OpenSSO to connect to Shibboleth 2 IDP's has become very easy with the latest changes in OpenSSO.  
These are the steps to accomplish this :

  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.

Turn OpenSSO into a Shibboleth 1.x SP/IDP

The following was posted in the opensso users mailinglist, that a lot of people found very interesting to say the least !

Chris Phillips ( wrote an article on how OpenSSO Enterprise can be configured as an Shibboleth 1.3 IDP.
The article can be found at :

Academic World : Here comes OpenSSO !
Technorati Tags:

Tuesday Dec 16, 2008

Keep a full SSO experience for end-users while migrating a custom SSO product to OpenSSO

Ever seen a customer ask the following ?

We have a custom made Web-SSO solution, and would like to migrate to OpenSSO.  How can we do this in an application by application fashion, by having the 2 solutions coexist during the migration phase ?The easy answer would be : use federation.  But the lack of federation capabilities may very well be the reason why they want to move to OpenSSO, or the customer may not want to spend money by adding federation functionality to a product that is about to be phased out.

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.
As a result the following is true :
  • 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.

Wednesday Dec 10, 2008

Using SAML 1.x or SAML 2.0 to authenticate Sharepoint users

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.


Bert Van Beeck is a Senior Software Architect at Sun Microsystems, specialized in Sun's Identity Management portfolio. He's part of the Northern European pre-sales software team.


« July 2016