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 !

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.

Friday Jun 20, 2008

New consolidated wiki on OpenSSO/Federated Access Manager

As more and more documents on OpenSSO are being written all over the Internet, this information is now bundled in a central wiki.


It contains information on product architecture, early-access documentation, FAQ's en Technical articles targeted at the developers community etc.  Also all the video based product demonstrations (for instance the ones one federation, the fedlet, the federation validator, etc ... are contained).

Have fun reading !

Thursday Jun 12, 2008

OpenSSO/FAM and the Belgian Identity Card (EID)

People keep asking me whether Sun's identity management solution supports the EID card for authentication out-of-the-box.  The answer is YES.

OpenSSO/FAM can use the EID certificate via X509, leveraging the EID middleware and the browser' SSL backchannel.
In order to map the certificate to a local LDAP account/profile, you can either have that account created on the fly, use a transient session that only keeps the profile in memory and deletes it afterwards, or map it to an existing profile by adding the certificate public key as an attribute to the OpenSSO used LDAP repository.

For more information on how to configure the OpenSSO environment for use of EID, please look at Sebastien's article :

Another way of dealing with is would be to use Federation (f.e. SAML 2) connecting OpenSSO to a SAML enabled identity provider using EID as a means of authentication.   That way, an assertion would be sent to OpenSSO that could be used to create a session for the intended account.
IDP's with this capability that do not currently have SAML 2 functionality embedded in the product may want to take a look at the newly added Fedlet and Federation Validator functionality added in OpenSSO. It is both intended for SP's and IDP's.
See :

OpenSSO and WebSynergy

This week, I attended the introductory bootcamp on Sun's newest portal initiative : Portal Websynergy.

It dealth with the evolutionary process of the joined partnership between Liferay and Sun, in particular the way Sun is injecting Sun Java System Portal Server capabilities into the current Liferay Portal, an open-sourced merger known as a separate portal product currently called "Project WebSynergy".

See: and

What was interesting to see is that the new WebSynergy portal is no longer tightly connected to the Sun Java System Access Manager (or Federated Access Manager as known starting with released 8.0), but now is connected with OpenSSO/FAM 8.0 for pure authentication and identity attribute delivery purposes only.

The connection with OpenSSO is configured via the admin widgets in WebSynergy :
You specify 4 parameters : Login URL (towards OpenSSO incl.goto parameter), LogOut URL, Service URL (using the new OpenSSO REST  identity webservice to obtain identity information), and the CookieName.
This means it does not need the OpenSSO Api nor does it need a Policy Agent installed.

Info on the OpenSSO REST webservice:

WebSynergy also allows local authentication via internal user repositories (filesystem, RDBMS, ...) , onboard LDAP synchronisation with that local store etc.

Also keep in mind that, even though WebSynergy is a perfect fit for Developer/Web2.0 oriented start-ups (and adds additional functionality on top of the classic LifeRay Portal), the enterprise features as currently known in Sun Java System Portal Server 7.2 will be added in a high pace to this new portal platform.
The same is true for it's authorisation/authentication capabilities and Identity Based Content Delivery functionality.

I'm looking forward to see how Identity Manager could be coupled with this environment, allowing it to provision profile data into the local WebSynergy portal, whilst provisioning an account into the LDAP/OpenSSO repository for authentication 


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