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=<myattribute>
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.