Configure a SAML Application

The SAML configuration is generic using the SAML 2.0 standard and has been tested with several Service Providers including AWS, Zoom, Palantir, Wordpress, JIRA, and Google.

Note: When you integrate Auth with an application using SAML, Auth acts as the Identity Provider (IdP) and the external application is the Service Provider (SP).

Configuring a connection to a SAML SP using the LabShare Auth UI

Steps

  1. Login to the Auth UI (ng-auth) instance connected to the LabShare Auth API service.
  2. View or create an Tenant.
  3. From the main Tenant dashboard, go to the Providers dashboard on the left navigation menu to register one or more Identity Providers.
  4. Navigate to the Applications dashboard and click the Add New button.
  5. In the form, specify the name, optional OAuth clientID (defaults to a UUID), and set the type to saml.
  6. Select the identity providers for the application. This step will connect the user directories from the identity providers to the SAML OAuth client. For example, assigning a Google IdP to the SAML IdP OAuth Client would allow anyone with a Google account to access the SAML Service Provider the SAML IdP is associated with.
  7. (Optional) Restrict access using User Groups or Active Directory Groups. Details: authorization.
  8. In the JSON editor, provide the configuration options for the SAML IdP listed below based on the requirements of the SAML Service Provider.
  9. After creating a new SAML application, click on the settings icon next to the new entry in the Applications dashboard view/download the IdP metadata in the Details tab.

Options

By default, none of the options below are required when configuring a new SAML2 IdP.

Property Type Details
claims object An object containing key/value pairs for custom claims to add or remap in the SAML assertion.
recipient string The assertion Recipient.
audience string The assertion Audience.
destination string The assertion Destination.
lifetimeInSeconds number The SAML assertion lifetime.
relayState string Overrides or assigns default RelayState for Service Providers.
nameIdentifierFormat string Specify the NameID format. Example: urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress. Default: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
nameIdentifierProbes array A list of claim URNs to prioritize when determining the NameID value.
encryptedAssertion boolean Encrypt assertion using certificates provided by the Service Provider.
logout object Configure the Service Provider SAML Single Logout URL
logout.callback string The Service Provider SAML Single Logout URL. Required for SLO.
binding string The protocol binding to use for the SAML SLO response. Default: ‘urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST’
signResponse boolean Default: false. If false only the assertion is signed. If true the entire response is signed. (Signing the response is preferred if that is supported by the client).
signingCert string The public signing certificate of the Service Provider used to validate the SAMLRequest. Recommended to avoid tampered SAMLRequests. Default: null
scripts object Scripts to customize the behavior of the SAML IdP. Default: null
scripts.mapClaims string A script for mapping the raw profile claims to assertion claims in the SAML response. Replaces the default claim mapping behavior when provided. Default: ‘’

Example

{
  "lifetimeInSeconds": 7200,
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
  "audience": "https://signin.aws.amazon.com/saml",
  "recipient": "https://signin.aws.amazon.com/saml",
  "destination": "https://signin.aws.amazon.com/saml",
  "claims": {
    "https://aws.amazon.com/SAML/Attributes/SessionDuration": 43000,
    "https://aws.amazon.com/SAML/Attributes/RoleSessionName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  },
  "scripts": {
    "mapClaims":
      "#!v8-isolate\n" +
      "export default function (context) {\n" +
      "  const claims = context.secrets.claims;\n" +
      "return {\n" +
      "  \"http://my.claim.urn\": claims.given_name\n" +
      "  \"http://my.claim.urn2\": claims.family_name\n" +
      "});"
  }
}

Custom Integrations

Configuring a custom SAML integration provides additional functionality such as user provisioning for Service Providers such as Google, JIRA, and Azure.

Steps

  1. Login to the Auth UI
  2. Select a Tenant
  3. Go to the Applications dashboard
  4. Select an existing SAML application
  5. Go to the Integrations tab in the dialog
  6. Select the integration type
  7. Specify the options for the selected type as a JSON object in the editor
  8. Save changes

GSuite

Note: A super user account on GSuite is required

Steps

  1. Configure a new SAML IdP in Auth. Set the logout.callback value to https://accounts.google.com/logout.

Example (replace my.account with the GSuite account name):

{
  "logout": {
    "callback": "https://accounts.google.com/logout"
  },
  "adGroups": ["My AD Group"],
  "audience": "https://www.google.com/a/my.account/acs",
  "recipient": "https://www.google.com/a/my.account/acs",
  "destination": "https://www.google.com/a/my.account/acs",
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email"
}
  1. Follow the instructions at https://support.google.com/a/answer/60224?hl=en to use the new SAML IdP for the Google domain managed by your account.
  2. Follow the instructions at https://developers.google.com/admin-sdk/directory/v1/guides/delegation to assign API and client permissions and obtain the client-secrets.json for a service account on the Google domain.
  3. Ensure the following scopes are assigned at the Manage API Client Access section (second section of delegation configuration document linked above): https://www.googleapis.com/auth/admin.directory.user and https://www.googleapis.com/auth/admin.directory.group
  4. Assign the data from the client-secrets.json file to the clientSecrets option of the SAML config.

Example GSuite SAML configuration

GSuite integration options
Property Type Details
verifiedDomain string A verified domain linked to the Google domain. Required.
clientSecrets object The service account secrets in JSON format. Required.
domainAdministratorEmail string The email address of an admin of the Google domain. Example: my.user@my.domain.org. Required.
assignOriginalDomainToEmail boolean EXPERIMENTAL: Assign original domain to user email. Example: dave.smith@original.domain becomes dave.smith.original.domain@verified.domain. This helps prevent email conflicts when multiple IdPs are configured for the SAML IdP. Default:true.
mapIdpToVerifiedDomain array EXPERIMENTAL: Assign user domain based on the IdP name used for authentication. Optional.

Example

{
  "verifiedDomain": "my.google.domain",
  "clientSecrets": "******",
  "domainAdministratorEmail": "admin@my.google.domain",
  "assignOriginalDomainToEmail": false,
  "mapIdpToVerifiedDomain": [
    {
      "connection": "my-nih-idp",
      "domain": "my.google.domain"
    },
    {
      "connection": "my-azure-idp",
      "domain": "another.verified.domain"
    }
  ]
}

JIRA

Note: Obtaining an API token requires administrative access on the JIRA domain

Steps

  1. Configure a new SAML IdP in Auth.
  2. Create an API Token by following the instructions at https://confluence.atlassian.com/cloud/api-tokens-938839638.html.
  3. Configure the integration property with a JSON object containing the following attributes:
JIRA Cloud integration options
Property Type Details
verifiedDomain string A verified domain linked to the JIRA site. Example: “labshare.org”. Required. See: https://confluence.atlassian.com/cloud/domain-verification-873871234.html
apiToken string A JIRA API token. Required. See: https://confluence.atlassian.com/cloud/api-tokens-938839638.html
domain string The JIRA site domain to provision the authenticated user on during a IdP-initiated flow. Example: “mysite” if the JIRA site is https://mysite.atlassian.net. Required.
domainAdministratorEmail string The email address of an admin of the JIRA site. For example, my.user@my.domain.org. Required.
assignOriginalDomainToEmail boolean EXPERIMENTAL: Assign original domain to their email. Example: dave.smith@original.domain becomes dave.smith.original.domain@verified.domain. Default: true.