Add a SAML Application

You can configure a connection between a SAML-enabled web application (the service provider, or SP) and SecurID (the identity provider, or IdP). This procedure adds the application to My Applications and makes it 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 and one identity source must be configured and connected to 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.
    • Signature and Digest details
    • Extended attribute names

Procedure

  1. In the Cloud Administration Console, click Applications > Application Catalog.

    The Application Catalog appears.

  2. Click Create From Template.

  3. Next to SAML Direct, click Select.

  4. On the Basic Information page, complete these fields.

    1. Choose where to enable your application for single sign-on (SSO). You can enable the application on cloud or identity router based portal. This option is available only if identity router based portal is enabled for you.

      Note: This option is not available for new customers.

    2. In the Name field, enter a name for the application.

    3. (Optional) In the Description field, enter a description for the application.

    4. (Optional) To make the application unavailable to users, select the Disabled checkbox. When disabled, the application appears in My Applications, but does not appear in the application portal.

      For information about how this setting interacts with the Display in Portal setting on the Portal Display page, see Application Availability and Visibility.

    5. Click Next Step.

      The Connection Profile page of the wizard appears.
  5. (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:
    1. 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.

      2. Note: The selected file must not exceed 150K in size, and must match standard SAML metadata schema.

    2. Review the highlighted rows that show settings with changed values that will be applied if you save.
    3. 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.
  6. 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.
      1. Select IDP-initiated.
      2. (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.
      1. Select SP-initiated.
      2. 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.
      3. For Binding Method for SAML Request, select the mechanism by which the identity router (IdP) receives the SAML request from the SP.
        Option Result

        Redirect

        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.

        POST

        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.

      4. (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.

  7. 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.
    1. For Issuer Entity ID, select the value for the identity router to include in the SAML response.
      Option Result

      Default (idp_id)

      Use the idp_id string, for example 1dwsi11agmqlw, as the issuer entity ID.

      Override

      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.

    2. 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: SecurID 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.

    3. 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.
  8. Complete settings for the Service Provider. These settings must match the configuration on the SP.
    1. In the Assertion Consumer Service (ACS) URL field, enter the URLs 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. You can add multiple URLs. Each URL is assigned with an index value. The first URL shows the index value 0 and is considered as the default URL. You can reorder and delete the URLs.
    2. 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.
  9. In the User Identity section, specify NameID information that identifies the user on whose behalf the SAML assertion is generated.
    1. For Identifier Type, select the format of the NameID. The format must correspond to how the SAML application identifies users.
      Option Description

      Email Address

      The NameID has the form of an email address.

      Subject

      The NameID has the form specified for the contents of the <ds:X509SubjectName> element in the XML Signature Recommendation [XMLSig].

      Unspecified

      The SP interprets the content of the element.

      Transient

      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.

      Persistent

      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.

    2. Select the Identity Source where user accounts are located.
    3. 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.
    4. (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.

  10. (Optional) The Connection Profile page has two additional fields: Authentication Context and Default Relay State.

    Authentication context refers to the information that is added to an assertion with details of the technology used for the actual authentication action. For example, a service provider can request that an identity provider complies with a specific authentication method by identifying that method in an authentication request. The identity provider then delivers (with the assertion) the authentication context information in the form of an authentication context declaration added to the assertion. This is an optional field. If no value is entered, then the following is used by default:

    • <samlp:RequestedAuthnContext Comparison="exact">

    • <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></samlp:RequestedAuthnContext>

    • </samlp:RequestedAuthnContext>

    Additionally, the following options are also supported:

    Format:

    • urn:rsa:names:tc:SAML:2.0:ac:classes:spec:<primary_auth>:<policy_name>

    • primary_auth literal values:

    • primary - perform primary authentication (and step-up). Primary auth method must be configured for the SP.

    • stepup - no primary authentication (step-up only)

    • If primary_auth is omitted, the default method configured for the SP is used. If policy_name is present, it overrides the default policy configured for the SP.

    Whereas, Relay State is a mechanism used to preserve and convey state information. When a SAML request message contains Relay State data, then the SAML responder returns its SAML protocol response using a binding that also supports a Relay State mechanism. It places the Realy State data it received into the corresponding Relay State parameter in the response. From a Single Sign On (SSO) perspective, it acts as an identifier for the Service Provider (SP) resource that the Identity Provider redirects the user to. The process of SSO is more transient to the user because they are redirected to the same page that they originally requested at the SP. If there is no Relay State in an IdP-initiated request, the default Relay State will return in the SAML response.

  11. 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.
    1. 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.
    2. Click Next Step.
  12. On the Portal Display page, configure how the application will appear in the application portal.
    1. (Optional) To hide the application in the application portal, clear the Display in Portal check box. 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.
      For information about how this setting interacts with the Disabled setting on the Basic Information page of the wizard, see Application Availability and Visibility.
    2. Select the Application Icon to represent the application in the portal. Use the default icon or click Change Icon to upload a different image.
      The image file must be in JPG or PNG format, and no larger than 50 KB. The recommended size is 75x75 pixels.
    3. In the Application Tooltip field, enter text that appears briefly when the cursor pauses over the application icon in the application portal.
    The Portal URL field is read-only, and displays the URL for the home page of the application.
  13. Click Save and Finish.
  14. (Optional) To publish this configuration and immediately activate it, click Publish Changes.

Results

After saving the SAML application configuration, you can export the IdP metadata from My Applications, and send it to the SP administrator. For instructions on exporting SAML metadata, see Export SAML Metadata From an Application on the Identity Router.

Note: SAML applications cannot be moved from IDR-based portal to My Page. If you want to switch to My Page, you need to create your SAML applications again on My Page.