Create SAML Authentication

For Oka users - Before creating the SAML authentication within Administration, it is recommended to define the application in Okta.

You will need to copy the XML metadata file from your single sign-on authentication provider to use in step 6 below.

To create a new SAML authentication server, complete the following steps.

  1. On the toolbar, click Access > Authentication Servers.
  2. Click Create and then select SAML.
  3. In the General Properties section, enter a Name for the server.
    • The Enabled check box is selected by default. This means that the server will be active.
  4. In the SAML Settings section, complete the following subsections:

User Schema

  • In the First Name Attribute box, type the user's first name. This is the field returned from your authentication provider that contains the authenticating user's first name.
  • In the Last Name Attribute box, type the user's last name. This the field returned from your authentication provider that contains the authenticating user's last name.
  • In the Email Attribute box, type the user's email address. This the field returned from your authentication provider that contains the authenticating user's email address.
  • In the Group Name Attribute box, type the name from the identity provider that contains the user's group membership.

For example, if in SAML a user has a "role" field with a value of "developers", then you would type "role" in this field box.

Request and Response Preferences

  • Select the Use Signed Request check box to indicate whether the initial login request that is sent to the identity provider from Security Manager should be cryptographically signed or not. If the request is signed, the identity provider can use the signature to verify that the message was not modified during transmission. Initial authentication requests are not particularly sensitive, so many identity providers do not require or even check if the message is signed.
  • Select the Required Signed Response/Assertion check box to indicate whether the authentication result from the identity provider should be cryptographically signed or not. Since the authentication result contains information that essentially grants access to Security Manager, signed response ensures that the message has not been modified during transmission from the identity provider. In order to validate a signature, the identity provider’s public key or certificate must have previously been installed.
  1. In the SAML Metadata Generator section, complete the following fields:
    • In the Service Provider Entity ID box, type a URL with the host name portion rooted in your organization's primary DNS domain.
    • In the Service Provider Host Name box, type the base DNS name or IP address where you access this instance of SIP. Do not include "https://" or trailing slashes.
    • Paste the XML metadata file from your single sign-on authentication provider in the Identity Provider Metadata field. It should begin with these elements: <EntityDescriptor...><IDPSSODescriptor...> ...
  2. Click Save & Generate Service Provider Metadata. The Service Provider Metadata is an XML metadata file that should be copied to your authentication provider. If the Service Provider Entity ID or Service Provider Host Name fields are modified, this file must be regenerated and re-submitted to your authentication provider.
  3. After generating the service provider metadata, you have three options to use to copy the XML metadata file back to your authentication provider:
    1. Open in a new window
    2. Download the XML to a text file
    3. Copy to clipboard

    Not all authentication providers require this step.

  4. Click Save.
  5. You can now add User Group Mapping.