Home › Category Archives › opensso

SAMLv2 Account Mapping with OpenSSO and Transient Federation

By default OpenSSO uses Persistent Federation for account linking between an IDP and SP when SAMLv2 is used.  This means two things from the point of view of a LDAP administrator.

1.  Ideally the data stores on both IDP and SP should have OpenSSO schema
2.  And the user entry should also be writable by the BIND DN defined in the Data Store.
To recap for persistent federation OpenSSO writes two attributes namely sun-fm-saml2-nameid-infokey and sun-fm-saml2-nameid-info to the users entry.  The sun-fm-saml2-nameid-infokey acts at the Opaque Handle.  It holds a uniquely generated random key that is common between the IDP and SP so that the two accounts can be linked.  BTW instead of using these two attributes, one can specify your own too.  This can be done under Configuration->Global->SAMLv2 Service Configuration.
To achieve this linking, a first time user first authenticates to the IDP and then to the SP.  This way the user is manually providing the link between the two accounts.  Once this link is established (by writing the above two attributes to the user's entry on each repository), the user no longer has to provide his credentials at the SP.  This is actually what federating an account is all about.
There are however scenarios where one or both of the (LDAP) repositories that hold the user entry are read-only and/or no schema modification is allowed.  This mandates the use of Transient Federation which basically does not write back anything to the user repositories, thus eliminating the need to worry about adding custom schema and also allows the ability to use a read-only repository.
To use transient federation all you have to do is to pass NameIDFormat=transient as a query parameter to the federation (SOAP) end point servlets.  For example


However by default transient federation account mapping on the SP sides maps to the anonymous user as OpenSSO needs a physical object to create a session (this is not entirely true but that is a topic for another day).  That means there is a many to one mapping from the IDP to the SP.  If you are passing in attributes or some other information, this is not very desirable.
To overcome the issue of anonymous mapping you need alternate ways to link the two disparate accounts together which is the responsibility of the Account Mapper.  OpenSSO engineers have already thought about these scenarios and added out-of-box functionality to the account mapper to support these scenarios.

Below are two ways of doing it without any customizations to the account mapper.  Both require user repositories and obviously require a common attribute (and value) that links the accounts together (we would like to read your mind and provide a mind mapper but it is not possible with today's technology).  Also both methods utilize transient federation so that nothing is written to the data store (user repository).

Method 1

On the hosted IDP

1.  Click on Federation->IDP name->Assertion Content
2.  Modify (delete and add) "transient" to as follows
     For example:  urn:oasis:names:tc:SAML:2.0:nameid-format:transient=uid

On the hosted SP

1.  Click on Federation->SP name->Assertion Processinog
2.  On the account mapper check  "Use name ID as user ID"
 *** Note the above method requires Express build 8  or later on the SP side.

Method 2


On the hosted IDP

1.  Click on Federation->IDP name->Assertion Processing
2.  In the Attribute Map  add idpattribute=spattribute
     For example uid=uid

On the hosted SP

1.   Click on Federation->SP name->Assertion Processing
2.   Check Auto Federation. And provide the attribute name specified in step 2 above.  For example uid.
*** Make sure that the NameIDFormat=transient is used as a query parameter to either the idpssoinit or spssoinit servlet.

OpenSSO 8 & SAML v2 AttributeStatement

A very useful and essential feature of OpenSSO is to allow attribute mappings.  This enables you to send addtional attributes in the SAMLv2  assertion/response to the Service Provider.  Once the attribute mapping is defined (can be done either from the GUI under the entities “Assertion Processing” tab or in the metadata itself), the map is sent as a name-value pair to the Service Provider.  Also keep in mind that the mapping can and should be defined on the remote service provider so that if your hosted IDP is shared amongst multiple SP’s, each can have their own mapping.  For example here the map was defined from the GUI as USERID=employeeNumber for one of the remote SP’s.

<saml:AttributeStatement><saml:Attribute Name="USERID"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">121898</saml:AttributeValue><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">007</saml:AttributeValue></saml:Attribute></saml:AttributeStatement>

Once the Service Provider receives the assertion and has been configured to look for the attribute name USERID, it will grab the value and do whatever it needs to.  One such real life example is SalesForce.com CRM.  In OpenSSO 8 Express Build 8, there is a wizard to support easy configuration of federation with SalesForce.com which results in a map definition automatically.

One problem that i ran into (not related to the product, phew..) was that however many maps i defined i could not see them in the assertion.  As a matter of fact i could not even see the <saml:AttributeStatement> tag.  Turns out that earlier i had modified the Authentication->Core setting from Profile=required to Profile=ignored.  Reverting back to Profile=required fixed the issue and the assertion started to pass the attributes.

OpenSSO Agent 3.0 and SSL Termination

While working with a customer whose J2EE 3.0 agent was (deployed on Tomcat 6 in non-SSL mode) behind a SSL enabled load balancer i.e., SSL Terminated, we had to set these two properties in the centralized configuration of the Agent under the “Advanced” tab to make it work properly otherwise obviously the agent was redirecting everything to http and port 80 which the Load Balancer was blocking.  Also note that we created the policies with a resource of “https” (as desired).


Identity Suites Essentials OpenSSO Tutorials

We have just made available an internal suite of tutorials to the public on http://wikis.sun.com/display/ISE

These tutorials include step by step installation and configuration information both for OpenSSO and Identity Manager.   They also include common post installation use cases that we have seen deployed at various customers.
I intend to continue contributing additional tutorials/use cases to the OpenSSO Tutorial so keep watching it. 

How to Federate with Google Apps using OpenSSO as the Identity Provider

My colleague Pat Patterson had written a howto on how to Federate with Google Apps using an much older build of OpenSSO.  At that time he had to use a custom account mapper (i.e. write code) to map the NameID in the SAML v2 response.  Now with the latest OpenSSO builds the custom account mapper is no longer required as account mapping for SAML v2 is supported OOTB using the administrative console of OpenSSO thanks to Heng-Ming Hsu (another colleague) who recently added this functionality to OpenSSO's DefaultIDPAccountMapper.


Here is a simple writeup on how to federate with Google Apps using OpenSSO.  I did this in less than 10 minutes but i already had Glassfish installed and opensso.war deployed. Note that this writeup is using non-SSL connections.  In production it is recommended to use SSL enabled web servers.




OpenSSO latest nightly build
* http://download.java.net/general/opensso/nightly/latest/opensso/opensso.zip  (i used Oct 6th build)

Any OpenSSO Supported Container
* http://opensso.dev.java.net/public/use/docs/fampdf/rn.pdf
* I used Glassfish V2R2 http://glassfish.dev.java.net

A Premier Account for Google Applications 
* http://google.com/a




The OpenSSO is the Identity Provider (IDP) and Google Apps is the Service Provider (SP).  We will use SAML v2 as the Single Sign-On (SSO) protocol between the two and create a Circle Of Trust (COT) on the IDP.


Note your browser will need the Quicktime(TM) plugin to view the videos


1.  Deploy opensso.war on your container


Download opensso.zip, extract opensso.war and deploy it on your container.  For Glassfish it is very simple and done via the “asadmin deploy” command (for the feint hearted the Glassfish administrative console can also be used to deploy the war file).


Carefully read the release notes to see if your container requires any pre-deployment tasks such as modifying your container's server.policy file


-bash-3.00# ./asadmin deploy –user admin –passwordfile /var/tmp/asadmin_passwd  –port 4848  –enabled=true –contextroot /opensso /var/tmp/opensso/deployable-war/opensso.war
Command deploy executed successfully.
-bash-3.00# ./asadmin stop-domain 
Domain idp stopped.
-bash-3.00# ./asadmin start-domain


Starting Domain idp, please wait.Log redirected to /var/opt/glassfish/domains/idp/logs/server.log.
Redirecting output to /var/opt/glassfish/domains/idp/logs/server.log
Domain domain1 is ready to receive client requests. Additional services are being started in background.
Domain [idp] is running [Sun Java System Application Server 9.1_02 (build b04-fcs)] with its configuration and logs at: [/var/opt/glassfish/domains].
Admin Console is available at [http://localhost:4848].
Use the same port [4848] for "asadmin" commands.
User web applications are available at these URLs:
[http://localhost:8080 https://localhost:8181 ].
Following web-contexts are available:
[/web1  /__wstx-services /opensso ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://utopia:8686/jmxrmi] for domain management purposes.
Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ].
Domain does not support application server clusters and other standalone instances.


2.  Configure OpenSSO after deploying to your container


Run though the OpenSSO configuration wizard by pointing your browser to the containers URL and opensso context.  In my case it is http://idp.unopass.net/opensso


* To download this video click here



3.  Configure IDP on OpenSSO via the Workflow Wizard


One of the defining features of OpenSSO is its workflow wizards which help you to create a hosted IDP/SP or remote IDP/SP very quickly without the need to create metadata files and importing manually.


* To download this video click here



4.  Configure SP on Google Apps


* To download this video click here



5.  Define Name Identifier (NameID) mapping


Google Apps requires that the userid be sent back in the SAML response.  OpenSSO does not do this by default but now provides a very simple way of mapping the nameid to any attribute in the users profile (in the ldap directory).


* To download this video click here



6.  SSO into Google Apps using your new OpenSSO IDP


Finally test the SSO by trying to access http://mail.google.com/a/<your domain>.  You should NOT be prompted by the traditional Google Login screen, rather you should be redirected to IDP's (OpenSSO) Login page.  You should log into OpenSSO with the same userid but password can be different (Hint: you need to create this user if it does not already exist in OpenSSO).


* To download this video click here



After watching this video keep in mind that SSO demos are never impressive unless you show what is happening behind the scenes.    One way to do so is to show the SAML 2 protocol (SOAP) messages. 


The good news is that they can be grabbed from the debug logs of OpenSSO.  You have to enable “message” level debugging first form the OpenSSO Administrative Console under Configuration->Sites.  You will then be able to see the AuthN requests and SAML assertion in the debug log called “Federation”.  For example.


AuthN Request


<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="glcmf
hikbbhohichialilnnpjakbeljekmkhppkb" Version="2.0" IssueInstant="2008-10-14T00:5
7:14Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Provider
Name="google.com" IsPassive="false" AssertionConsumerServiceURL="https://www.goo
gle.com/a/unopass.net/acs"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:
assertion">google.com</saml:Issuer><samlp:NameIDPolicy AllowCreate="true" Format
="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /></samlp:AuthnRequest>




IDPSSOUtil.sendResponse: SAML Response content :
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s247893b2ec9
0665dfd5d9bd4a092f5e3a7194fef4" InResponseTo="hkcmljnccpheoobdofbjcngjbadmgcfhaapdb
nni" Version="2.0" IssueInstant="2008-10-15T17:24:46Z" Destination="https://www.goo
gle.com/a/unopass.net/acs"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:ass
ertion">http://idp.unopass.net:80/opensso</saml:Issuer><samlp:Status xmlns:samlp="u
<samlp:StatusCode  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
</samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" I
D="s295c56ccd7872209ae336b934d1eed5be52a8e6ec" IssueInstant="2008-10-15T17:24:46Z"
<saml:Issuer>http://idp.unopass.net:80/opensso</saml:Issuer><Signature xmlns="http:
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#s295c56ccd7872209ae336b934d1eed5be52a8e6ec">
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQua
tion Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="hkcmljnccpheoobdofbjcngjbadmgcfhaapdbnn
i" NotOnOrAfter="2008-10-15T17:34:46Z" Recipient="https://www.google.com/a/unopass.
</saml:Subject><saml:Conditions NotBefore="2008-10-15T17:14:46Z" NotOnOrAfter="2008
<saml:AuthnStatement AuthnInstant="2008-10-15T17:24:46Z" SessionIndex="s2bb816b5a88



OpenSSO custom auth module for RSA Access Manager (formely ClearTrust)

I have just checked in code for a custom auth module that validates a RSA ClearTrust SSOToken (CTSESSION) in the OpenSSO CVS repository.  This was a result of getting inspired by the much more feature rich SiteMinder module.

Just like the SiteMinder auth module, the obvious two use case of this module are:


  • Co-existence with OpenSSO while authenticating to ClearTrust

  • Migrating to OpenSSO in a ClearTrust environment

This module has been deployed in production and a colleague of mine has polished the code a bit more (my Java skills are ahm…lets say require a jump start most of the time).  I'll be checking in the polished code later next week.

For details on deploying this module refer to the README.txt file in the following directory