Configure a custom connection between a SAML-enabled web application (the service provider, or SP) and RSA SecurID Access (the identity provider, or IdP). After you complete this procedure, the application is added to My Applications and is available for single sign-on (SSO) after the next publish operation.
You can configure your own connection between a SAML-enabled web application (the service provider, or SP) and RSA SecurID Access (the identity provider, or IdP). After you complete this procedure, the application is added to My Applications and is available for single sign-on (SSO) after the next publish operation.
Before you begin
You must be a Super Admin for the Cloud Authentication Service to perform this task.
Contact your SaaS application provider to learn about their SAML policies and how much time they need to enable the SAML configuration. Plan your timetable accordingly.
At least one identity router must be configured and connected.
At least one identity source must be configured and connected for the Cloud Authentication Service.
Collect the SSO configuration settings for the web application to which you are configuring the connection. For example, you need to know:
The SSO profile for the SAML connection: IdP-initiated or SP-initiated. For more information, see SAML Applications .
The URL for the Assertion Consumer Service (ACS) on the SP.
The entity ID for the SP.
The format of the name identifier (NameID) that the SAML application uses to identify users. For example, a corporate ID might be required to authenticate to an Active Directory domain; an email address is required to authenticate to Google Apps; Salesforce allows different types of identifiers.
(Optional) If you want to import SAML SP metadata, obtain the metadata file from the SP. Importing the metadata adds the following properties to the SAML configuration:
SP Entity ID
Supported name identifier formats such as email, subject, or unspecified
Assertion Consumer Service (ACS) URL
ACS Binding (should be POST)
The SP might also provide the following metadata:
If AuthNRequests are signed, the SP provides the certificate so that the identity router can verify the signature on the request.
The Connection Profile page of the wizard appears.
(Optional) To import SAML metadata from the SP and automatically populate SP-related fields on the Connection Profile page, click Import Metadata. In the Import SAML Metadata dialog box, do the following:
Click Choose File to locate the XML file you want to import. The file has a name similar to application_SAML2_Direct-SP-metadata.xml.
Note:The selected file must not exceed 150K in size, and must match standard SAML metadata schema.
Review the highlighted rows that show settings with changed values that will be applied if you save.
Click Save to import the metadata.
After you import SAML metadata, you can still manually configure settings on the Connection Profile page. If you re-import and save the metadata, however, any manual changes you made previously are overwritten.
In the Initiate SAML Workflow section, specify the SSO workflow for this SAML connection.
If the workflow is initiated by the IdP, perform these steps.
(Optional) In the Connection URL field, enter the URL for the protected resource at the SP. You can leave this blank unless the SP requests a specific value. If it is blank, the SP normally forwards users to the correct resource.
If the workflow is initiated by the SP, perform these steps.
In the Connection URL field, enter the URL that initiates the SSO authentication process from the SP side. This is usually the home page of the SP, for example, https://mydomain.serviceprovider.com.
For Binding Method for SAML Request, select the mechanism by which the identity router (IdP) receives the SAML request from the SP.
The SP uses the HTTP Redirect binding (HTTP GET) to append the SAML request as a URL query parameter (subject to length limitations), and pass it to the IdP.
The SP uses the HTTP POST binding to encode the request in an XHTML form (no size limitations), and pass it to the IdP as a POST URL parameter.
(Optional) If you want the SP to sign the SAML request, select Signed and click Choose File to load the SP certificate. You must also load the corresponding private key in the SP.
Signing the SAML request ensures that the identity router only accepts signed requests from the SP. Otherwise the identity router accepts any SAML request, signed or not.
Note:Signing SAML requests is not supported if you selected the Redirect binding method in step 6-c.
Specify Identity Provider settings to identify for the SP who issues the SAML response containing the SAML assertion, and its intended domain or application.
The Identity Provider URL is the URL to which the SP passes the SAML request. The field is prepopulated with the identity router URL, appended with an idp_id string that matches the idp_id that was generated when the application was created. For example, https://mydomain.example.com/IdPServelet?idp_id=1dwsi11agmqlw. This is the URL to which the SP posts the SAML request, and from which the IdP issues the SAML response. The identity router identifies the application by the idp_id.
For Issuer Entity ID, select the value for the identity router to include in the SAML response.
Use the idp_id string, for example 1dwsi11agmqlw, as the issuer entity ID.
Enter an issuer entity ID that is different from the idp_id string. For example, some applications require that the issuer entity ID have the form of a URL, such as http://mycompany.com.
In the SAML Response Signature section, upload a private key and public certificate that form a valid key pair.
Click Choose File to locate and import the private key (private.key file) to sign the SAML assertion. The private key must correspond to the public signing certificate loaded in the SP application. This is how the SP validates the SAML assertion that it receives from the identity router.
Click Choose File to locate and import the certificate that the SP can use to validate the signature. The file must be in x509 v3 (PEM) format.
Note:RSA SecurID Access requires version 3 certificates and generates only version 3 certificates in certificate bundles. The Cloud Administration Console does not check the certificate version during upload. If you upload a certificate that is not version 3, the identity router may not function properly. If you suspect this has occurred, obtain and upload a version 3 certificate. If you cannot obtain a version 3 certificate, use the Cloud Administration Console to generate a certificate bundle and upload the certificate from the bundle.
If the SP requires the certificate to be included in the SAML response, select Include Certificate in Outgoing Assertion. Otherwise, do not check this box.
Complete settings for the Service Provider. These settings must match the configuration on the SP.
In the Assertion Consumer Service (ACS) URL field, enter the URL for the Assertion Consumer Service (ACS) on the SP where the SAML response is posted. The SP ACS URL monitors the site for SAML assertions, validates assertions, and grants users access to the application. For example: https://ServiceProvider.example.com/ecp_assertion_consumer.
In the Audience (Service Provider Entity ID) field, 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.
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.
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 SP interprets the content of the element.
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 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.
Select the Identity Source where user accounts are located.
Based on the selected identifier type and identity source, select the Property (attribute) to use as the NameID. Attributes selected on the Identity Source > User Attributes page are available for this application.
(Optional) To specify one or more attributes to map to the NameID when user identities reside in multiple identity sources, select Attribute Hunting and click NameID Attribute Hunting. In the Attribute Hunting Details dialog box, select a Identity Source and Property (attribute) value pair to map to the NameID attribute in the SAML assertion. Click ADD to specify additional identity source/property pairs.
This step completes the minimum required Connection Profile settings for the SAML configuration. Optional, advanced settings are available as described in Configure Advanced Settings for a SAML Connection. You can complete the remaining, required steps in this procedure now, and if necessary, configure advanced settings later. Or, you can configure advanced settings now, and then complete this procedure.
On the User Access page, select an access policy that determines which users can access the application in the application portal, and whether those users must perform step-up authentication in order to use the application.
Select one of the following:
Allow All Authenticated Users – Allow all users signed into the application portal to access the application with no step-up authentication required. This is a built-in access policy that you cannot modify.
Select a Policy – Select an access policy from the drop-down list. The default is No Access Allowed, which denies access to all users. No Access Allowed is a built-in access policy that you cannot modify.
Click Next Step.
On the Portal Display page, configure how the application will appear in the application portal.
(Optional) To hide the application in the application portal, clear the Display in Portal checkbox. When unselected, the application is not visible in the application portal, but users can still access the application by going directly to the protected URL.