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.