InCommon Federation provides federated identities for academic communities. As an identity administrator for an educational institution that is a member of InCommon Federation, you can configure your enterprise to accept login for access to Adobe applications using an InCommon Federated ID.
When the user tries to sign in with Federated ID, Adobe sends a request to your IdP, which attempts to authenticate the user. After authentication, the IdP sends a response message to sign the user in and Adobe grants authorization for its services to the user.
Each IdP stores identity information differently, which means that you must create a mapping between the specific fields that your IdP uses, and the fields that are required for the corresponding Adobe ID. The mapping must go both ways. You must configure your Adobe organization with your IdP contact and mapping information, and you must configure your IdP with contact and mapping information for your Adobe organization.
To complete the configuration process, you must be an identity administrator with appropriate access privileges for both your Adobe organization account and your IdP account. You must have the following:
- A working SAML 2.0 compliant IdP. InCommon Federation members typically use Shibboleth 2.x or 3.x as their IdP, but that is not required.
- Administrative access to both the Adobe Admin Console and the InCommon Federation Manager.
- Administrative access to your IdP metadata.
- An approved domain claim for your Adobe organization account.
For your organization to allow SSO access to Adobe applications through your InCommon Federated IDs, you must do two things:
- Use the Adobe Admin Console to configure your organization with the security details of the IdP that you use to authenticate your InCommon Federation IDs.
- Use the InCommon Federation Manager to configure a Service Provider entry for Adobe connections.
To Configure Single Sign-On for your domain, enter the required information using the Set Up Domain wizard in the Adobe Admin Console.
You must fill in these fields to enable Adobe to connect to your service provider and allow users to log in with their InCommon Federated IDs.
- IDP Certificate: The PEM-format certificate in your IdP metadata. The file must have the extension .crt
- IDP binding: HTTP-POST or HTTP-REDIRECT.
- User login setting: Choose whether users log in with an email address or a simple username.
- IDP issuer: The entity ID of your IdP.
- IDP Login URL: The SAML login endpoint, as required for the Binding you specify.
To access the metadata file for the new service provider, click Download Metadata. Use this file to configure your SAML integration with the Identity Provider. Your Identity Provider requires this file to enable Single Sign-On.
A connection to Adobe requires a custom Service Provider in the InCommon Federation Manager. The Service Provider entry maps identity information between the Adobe Federated ID format and the InCommon Federated ID format used by your IdP. You find the Adobe values in the service-provider metadata file you downloaded from Admin Console.
To create a Service Provider entry, use the following steps.
The Adobe Service Provider requires that the IdP provide three custom attributes with these specific case-sensitive names:
- FirstName: Equivalent of `sn` (`surname`) InCommon attribute (urn:oid:22.214.171.124)
- LastName: Equivalent of `givenname` InCommon attribute (urn:oid:126.96.36.199)
- Email: Equivalent of `mail` InCommon attribute (urn:oid:0.9.2342.19200300.100.1.3)
As the corresponding InCommon attributes do not use the same names, you must configure your IdP to map the values and send them as custom attributes. If you use Shibboleth as your IdP, see their documentation for configuring custom attributes:
In addition to these custom attributes, you must configure the Subject attribute's NameId field to contain the value of the user's login username or email (as configured in the Adobe Admin Console). If you use Shibboleth as your IdP, see their documentation for configuring the NameIdfield: