Sun OpenSSO Enterprise 8.0 Administration Guide

Configuring SAMLv2 Single Sign-on without Service Provider User Accounts

Name identifiers are used by the identity provider and the service provider to communicate with each other regarding a user. Single sign-on interactions can support both persistent and transient identifiers. A persistent identifier is saved to a particular user entry as the value of two attributes. A transient identifier is temporary and no data will be written to the user's data store entry. OpenSSO Enterprise supports persistent identifiers by default and transient identifiers with configuration. NameID formats other than persistent and transient are supported by mapping the NameID format to a user profile attribute.

In some deployments, there might be no user account on the service provider side of an interaction. In this case, single sign-on with the transient name identifier is used. All users passed from the identity provider to the service provider will be mapped to this one user account. All attributes defined in the AttributeStatement will be set as properties of the specific user's single sign-on token. The following procedures describe some interactions using the transient name identifier.

ProcedureTo Use the Transient Name Identifier

  1. Append the NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient query parameter to the URL that initiates a single sign-on JavaServer Page™ (JSP™).

    spSSOInit.jsp and idpSSOInit.jsp both initiate single sign-on interactions.

  2. To test, invoke the URL.

    For more information, see Sun OpenSSO Enterprise 8.0 Developer’s Guide.

ProcedureTo Federate Disparate Accounts with Auto Federation

The auto-federation feature in OpenSSO Enterprise will automatically federate a user's disparate provider accounts based on a common attribute. This common attribute will be exchanged in a single sign-on assertion so that the consuming service provider can identify the user and create account federations. If auto-federation is enabled and it is deemed that a user at provider A and a user at provider B have the same value for the defined common attribute (for example, emailaddress), the two accounts will be federated automatically without principal interaction.


Note –

Auto-federating a principal's two distinct accounts at two different providers requires each provider to have agreed to implement support for this functionality beforehand.


Ensure that each local service and identity provider participating in auto federation is configured for it. Remote providers would not be configured in your deployment.

  1. In the OpenSSO Enterprise Console, click the Federation tab.

  2. Select the name of the hosted identity provider to edit its profile.

  3. Click the Assertion Processing tab.

  4. In the Attribute Map attribute, add the autofedAttribute=local-attribute value. For example, employeeNumber=employeeID.

  5. Click Save.

  6. Go back to the Federation tab and select the name of the hosted service provider to edit its profile.

  7. If the Auto Federation Common Attribute Name is the same as local attribute name, skip to next step. If not, enter the autofedAttribute=local-attribute value in the New Value field under Attribute Map. For example:

    employeeNumber=employeeID

  8. Click on the Auto Federation link at the top of the page, or scroll down to the Auto Federation subsection.

  9. Enable Auto Federation by checking the box.

  10. Click Save to complete the configuration.

ProcedureTo Map Attributes to anonymous User Account

In some deployments, the service provider side of an interaction might not store user accounts. The single sign-on solution is for all identity provider user accounts to be mapped to one service provider user account. Any attributes inside the Attribute Statement will be set as properties of the single sign-on token. The following procedure maps an identity provider user to a service provider anonymous user and passes two attributes to the service provider.

  1. In the console, select the identity provider you wish to configure.

  2. Edit Attribute Map attribute.

    attribute Map defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute-value=remote-provider-attribute. For example:

    mail=mail
    employeeNumber=employeeNumber
  3. From the console, select the service provider you wish to configure.

  4. Edit the following attributes for the service provider.

    • transient User will take a value of one of the existing transient user identifiers on the service provider side, for example, anonymous.

    • attribut eMap defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute_value=remote_provider_attribute. For example:

      >mail=mail
      employeeNumber=employeeNumber
  5. To test, invoke the single sign-on URL with the NameIDFormat=transient query parameter appended to it.

    All identity provider users will be mapped to anonymous on the service provider side. mail and employeeNumber will be set as properties in the identity provider user's single sign-on token.

ProcedureTo Achieve Single Sign-on Without Data Store Writes

This interaction uses auto-federation with the transient name identifier. There is one-to-one mapping between user accounts configured with the identity provider and the service provider based on the value of one attribute. The following procedure describes how to configure single sign-on without writing to the user's data store entry.

  1. Edit the following attributes in the OpenSSO Enterprise console for the identity provider.

    • Auto Federation – enable this attribute.

    • Auto Federation Attribute defines the common attribute on the identity provider side. For example, mail.

    • Attribute Map defines the mapping between the identity provider's attribute and the remote provider's attribute. It takes a value of autofedAttribute-value=remote-provider-attribute. For example:

      <Attribute name="attributeMap">
      <Value>mail=mail</Value>
      </Attribute>
  2. Edit the following attributes in the OpenSSO Enterprise console for the service provider.

    • Transient User takes a null value.

    • Auto Federation enable this attribute.

    • Auto Federation Attribute defines the common attribute. For example, mail.

    • Attribute Map defines the mapping between the provider that this metadata is configuring and the remote provider. This attribute takes a value of autofedAttribute-value=remote-provider-attribute. For example:

      mail=mail
  3. Invoke the single sign-on URL with the NameIDFormat=transient query parameter appended to it to test.

    All identity provider users will be mapped to the corresponding user on the service provider side based on the mail attribute but the auto-federation attributes will not be written to the user entry.