Monday Nov 23, 2009
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
http://myidp.wfoo.net:8080/opensso/idpssoinit?NameIDFormat=transient&spEntityId=...
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
urn:oasis:names:tc:SAML:2.0:nameid-format:transient=
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.
Friday Oct 30, 2009
Yes there are quite a few blogs on this but none of them is as complete as i would like it to be. So i am documenting my experience here.
1) First download the bits from Oracle. Key is to download the "Generic" Package Installer from here
2) Before starting to install you have to trick the installer into thinking that the local JDK is the generic Sun JDK. If you skip this step the installer will not accept the default Mac OS X JDK and complain that it is Invalid.
$ cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
$ sudo mkdir -p jre/lib
$ cd jre/lib
$ sudo touch rt.jar
$ sudo touch core.jar
3) Now install WLS using the following command. The installation is pretty straightforward.
$ java -Xmx1024m -Dos.name=unix -jar wls1031_generic.jar
4) The next challange is to overcome the java.lang.OutOfMemory error that occurs when you try to access the console at http://localhost:7001/console. As a result the server hangs.
To recover from this error you actually have to kill the JVM. So edit the user_projects/domains/mydomain/bin/setDomainEnv.sh script first and change the line "if [ "${JAVA_VENDOR}" = "Unknown" ] ; then" to "if [ "${JAVA_VENDOR}" = "Sun" ] ; then"
5) One last thing that is recommended is to set USER_MEM_ARGS="-Xms256m -Xmx512m -XX:MaxPermSize=128m" in startWebLogic.sh script. I added this as the first line.
6) Finally start the server
$ cd user_projects/domains/mydomain && ./startWebLogic.sh
Wednesday Sep 16, 2009
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 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.
Monday Aug 17, 2009
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).
Sunday Feb 08, 2009
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.
Thursday Sep 04, 2008
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
http://opensso.dev.java.net/source/browse/opensso/products/federation/openfm/integrations/cleartrust/
Wednesday Feb 28, 2007
- Grab openfm.war from opensso.dev.java.net
- In WS 7.0 create a new listener called fm or use web container of your choice.
- Deploy openfm.war to container
- Hit the deployed URL with web browser, it takes you to configurator.jsp
- Fill in the information, hit save, configuration failed.
- Looked at the webserver error log, apparently it is trying to create a directory /AccessManager.
- Realized that the user under which web server is running is webservd and by default the home directory for it is "/".
- Changed the home directory of webservd to /home/webservd, restarted the container
- Hit the configurator again, this time success!
Friday Aug 11, 2006
These notes are Java ES 3 (2005Q1).[Read More]
Friday Sep 30, 2005
The reason for my first blog is that i just spent a couple of hours trying to figure out why my mozilla was opening *.sxw documents with staroffice 7 whereas everywhere i looked it was associated to staroffice 8. Since i use KDE i was looking thru all the places where kde determines its MIME types and associated application. Then i thought that since mozilla is build on GTK+ perhaps it has an affinity to gnome, so i started looking under ~/.gnome, /usr/share/mime-info etc.
Finally thru a strace i saw the ~/.mailcap was being used. Once i moved/deleted this file, mozilla automatically picked up the mime type defined in KDE. But no wait actually later on i found out that it did not pick it up from KDE. It actally picked it up from /etc/mailcap which was added by Star Office 8 installation. So back to square one. Why can't there be a standard for this unless as usual i am ignorant and there is actually one. BTW i also thought that using gtk-qt-engine will help but it didn't. It did however help greatly in unifying my GTK+ look and feel to the same as KDE.
To me this is all a big mess. Every desktop application depending on what toolkit it is based on (or not based on) seems to have its own affinity to where to look for these MIME types!
Ah well i have vented my frustration. I feel better now!