Thursday Jan 29, 2009

Exciting new webcast on a demo involving 8 different SUN technologies

Ever wanted to see a demonstration on Identity Management in combination with Virtual Desktop Infrastructure technology ?
Here's your chance.

This demo involves the following integrated products : Sun OpenSSO Enterprise (SSO), Sun Identity Manager (provisioning & workflow), Sun Directory Server Enterprise Edition (account storage), Sun Ray Server (desktop), Sun Secure Global Deskop (virtualisation), Sun VirtualBox (virtualisation), OpenSolaris (OS) and Sun VDI (virtualisation).

Got you excited ?

More information:

Thanks Joachim and Paul for creating this marvel !

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.

Thursday Dec 04, 2008

Solaris vs Linux

I never considered myself an expert on Solaris nor Linux, but when presenting to customers and partners I often get the question which Operating System to choose, to host one of our identity management or portal products.
As this tends to be a customer's standard, there is always room for a debate when it comes to using open source OS's.

As Solaris opensourced under the name OpenSolaris, people tend to wonder which OS to choose when operating in an open source mode : Linux or Solaris (Open Solaris).
It is therefore that got interested in a discussion regarding the pro's and con's of these OS's, for which a summary was written in George Trujillo's Blog.

Click here for the summary on Solaris vs Linux

Friday Nov 14, 2008

Microsoft meets SAML2

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 :

Thursday Aug 07, 2008

Role Management through Identity Manager, Role Manager or Both

We have just release Identity Manager 8.0, which is a major upgrade compared to its predecessors in terms of provisioning, management and reporting of identities and their roles.

Identity Manager 8.0 introduces the idea of typed roles, such as Business Roles, Applications Roles, Asset Roles, IT Roles, Functional Roles, .... that can be used to group entitlements (attributes, LDAP groups, accounts, ...), and can then be assigned as a role to one or more identities.
The assignment of roles can be optional, mandatory, or conditially based on existing rules or rules made on the fly through the onboard wizard.

With the release of Role Manager 4.x, that product also provides similar role management capabilities.
The question then lies on when to use which of these management environments, when to use identity manager and/or role manager, when to combine both products, which product allows role mining, etc ....

All this and more is answered in a new webcast explaining all the new stuff in Identity Manager 8.0, and zooming in on combining Identity Manager and Role Manager in an set-up for role management needs.

The webcast can be found at :

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 !


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