You can configure your own connection between a SAML service provider (SP) and the Cloud Authentication Service as the SAML identity provider (IdP). The SP might be a third-party SSO solution or a web application.
Before you begin
- You must be a Super Admin in the Cloud Administration Console.
- Know which access policy to use for additional authentication.
- (Optional) If you want to import SAML SP metadata, obtain the metadata file from the SP. Otherwise, collect the following information from the SP:
- URL for the Assertion Consumer Service (ACS) on the SP
- Entity ID for the SP
- If the SP is signing the SAML requests, obtain the SP certificate that can be used to verify the signature. For more information, see Cloud Authentication Service Certificates.
Step 1: Enter Basic Information
In the Cloud Administration Console, click Authentication Clients > Relying Parties > Add a Relying Party.
From the catalog, select Service Provider and click Add.
On the Basic Information page, In the Name field, enter a name for the SP. This name appears in the Event Monitor and in the Authenticate app.
(Optional) In the Description field, enter a description for the SP.
Click Next Step.
Step 2: Configure Authentication Management
On the Authentication page, do the following:
If you want the Cloud Authentication Service to only manage additional authentication, select Service provider manages primary authentication, and RSA SecurID Access manages additional authentication.
If you want the Cloud Authentication Service to manage both primary and additional authentication select RSA SecurID Access manages all authentication.
Primary authentication (for example, password) is the initial identifying information of the user that is requesting access to the application.
If the Cloud Authentication Service is managing primary authentication, in the Primary Authentication Method drop-down list, select the authentication method to use. Note the following:
If you select FIDO, note that users cannot complete registration when authenticating for the first time with a FIDO authenticator as a primary authentication method. Be sure that users can first complete registration by accessing an application or My Page that requires FIDO as additional authentication. Then users can use FIDO as primary authentication for this application.
If you want to allow Emergency Tokencode as a replacement for FIDO (for example, if a user lost the FIDO authenticator), select Allow Emergency Tokencode to replace FIDO. Emergency Tokencode does not need to be in an assurance level to use it for primary authentication.
If you select the Emergency Tokencode option, consider the following additional authentication implications:
- If Emergency Tokencode is an authentication option based on the selected access policy, the user is granted access to the protected resource after entering the Emergency Tokencode one time and is not prompted for the Emergency Tokencode twice.
- If Emergency Tokencode is not an authentication option in the selected access policy, the user is prompted for additional authentication based on the policy.
If you select Determined by Service Provider at Run Time, configure the request to include the RequestedAuthnContext attribute as described SAML 2.0 Requirements for Service Providers.
If you want to allow Emergency Tokencode as a replacement for FIDO (for example, if a user lost the FIDO authenticator), select Allow Emergency Tokencode to replace FIDO. See the bullet item above for more information.
If you select Performed by Cloud Identity Provider, select the Cloud identity provider from the drop-down list.
In the Access Policy for Additional Authentication drop-down list, select the access policy to apply to SAML requests from this SP if primary authentication succeeds.
Click Next Step.
Step 3: Enter the Connection Profile
On the Connection Profile page, enter the SAML metadata to configure the relationship between the SP and IdP:
To automatically import the SAML metadata from an XML file, click Import Metadata and Choose File to locate the file you want to import. The file has a name similar to SP-metadata.xml.
After you import the file, the fields are populated. You can still manually configure settings on the Connection Profile page. If you re-import the file on this page and save the metadata, however, any manual changes you made previously are overwritten.
To manually enter the SAML metadata, click Enter Manually and enter the following settings. These settings must match the configuration on the SP.
Field Value Assertion Consumer Service (ACS) URL Enter the URL for the Assertion Consumer Service (ACS) on the SP where the SAML response is posted. The SP ACS endpoint accepts SAML responses with assertions, validates assertions, and grants users access to the application. For example: https://ServiceProvider.example.com/ecp_assertion_consumer. Service Provider Entity ID
Enter the entity ID that identifies the SP. Typically this is a URL, but a URL is not required. For example, https://ServiceProvider.example.com.
Specify the Audience string to include in the SAML response. You can select the Default Service Provider Entity ID or specify a different Audience in the Override field.
(Optional) If the SP is configured to sign the SAML request, select SP signs SAML request and click Choose File to load the SP certificate.
Selecting this option ensures that the IdP only accepts signed requests from the SP and rejects non-signed requests from the SP.
To verify the SAML assertion signature, under IdP Signs, select if the IdP signs the Assertion within response or Entire SAML response. Then click Download Certificate. Place the certificate in the necessary location for the SP.
Step 4: Configure Advanced Settings
Click Show Advanced Configuration. In the User Identity section, specify NameID information that identifies the user on whose behalf the SAML assertion is generated.
For Identifier Type, select the format of the NameID. The format must correspond to how the SAML application identifies users.
Option Description Auto Detect The IdP automatically detects the format included in the SAML assertion.
The NameID has the form of an email address.
The NameID has the form specified for the contents of the <ds:X509SubjectName> element in the XML Signature Recommendation [XMLSig].
The NameID is a persistent opaque identifier for a user that is specific to the IdP and SP. This identifier uses pseudo-random values that do not correspond with the user's actual identifier (for example, username). A persistent NameID remains the same each time the user authenticates.
The NameID has transient semantics that the SP treats as a temporary value. This value can identify a user without mapping to the user's actual account name. A transient NameID is different each time the user authenticates.
The SP interprets the content of the element.
Select or enter the Property (attribute) to use as the NameID value.
If you select Auto Detect, the IdP automatically detects the property included in the SAML assertion.
In the Attribute Extension sections, specify one or more NameID attributes. Each extended attribute can map to a single identity source/attribute pair.
Enter the name of the extended attribute.
- If the attribute is synchronized from an identity source, select Identity Source.
- To manually enter a value in the Property drop-down list, select Constant.
Select an attribute from the identity source, or manually enter the attribute. Attributes selected on the Identity Source > User Attributes page are available for this application.
- Click Save and Finish.
(Optional) To publish this configuration and immediately activate it, click Publish Changes.
After you finish
To collect the information needed to configure the service provider to connect with the Cloud Authentication Service, view or download the IdP metadata. For more information, see Manage Relying Parties.