Many organizations can serve as your Identity Provider for SAML.

The following sections describe how to configure the following providers:

No matter which Identity Provider you use, you should do the following:.

  1. Set the Signature algorithm name for SAML to SHA256withRSA.
  2. On your Identity Provider, configure the following Attribute Mappings (OneSpan Sign will use them to identify the user who is logging in):
  3. User Attributes
    email

    One of the following:

    • email
    • emailaddress
    • mail
    first name

    One of the following:

    • firstname
    • givenname
    • cn
    last name

    One of the following:

    • lastname
    • surname
    • sn
    accountid

    One of the following:

    • account
    • accountid
    • accountId
    type

    One of the following:

    • role
    • type
    • userType

If you want to configure an Identity Provider only for "recipients" (not members of a OneSpan Sign account), specify only the parameter email. You don't need to specify a first name or last name .

If you need to import the required metadata into your keystore, see Updating your SAML Certificate and Metadata

Additional Steps for Sub-Accounts

This section assumes that sub-accounts are enabled on your account. If that’s not true, you can ignore this section.

A user who has been added to your Identity Provider can be automatically added to OneSpan Sign. This is called auto-provisioning. Auto-provisioning is enabled for an account when the parameter allowSenderCreation in the file saml.config has the value true. This parameter is true by default.

When a user logs in to OneSpan Sign via an Identity Provider, they are already a OneSpan Sign user, or they aren’t. The following sections discuss these two cases:

Not a OneSpan Sign User

When someone who is not a OneSpan Sign user logs in to OneSpan Sign via an Identity Provider, either auto-provisioning has been enabled for them, or it hasn’t. The following sections describe those two cases:

Auto-Provisioning Enabled

If auto-provisioning is enabled, when someone who is not a OneSpan Sign user logs in to OneSpan Sign via an Identity Provider:

  • The user is re-directed to the Dashboard.

  • Auto-provisioning automatically adds the user to one or more sub-accounts, depending on the user attributes that have been configured for them in one of the following two procedures.

To add a user to a single sub-account:

  • You must configure the following user attributes:
    • accountid=<Account UID of the sub-account to which the user will be added>
    • role=<member or manager or owner>

To add a user to multiple sub-accounts:

  • You must configure the user attribute subaccounts with a JSON format like the following:

  • subaccounts = {"userType":"<user-type>", "phone":"<phone>", "subaccounts": [{"accountUid":"<UID1>", "roles":["role1", "role2",...]}, {"accountUid":"<UID2>", "roles":["role1", "role2",...]}, etc...]}

Here:

  • The possible values for <user-type> are Regular or Manager.
  • The possible values for a role are member or manager or owner.

Auto-Provisioning Disabled

When someone who is not a OneSpan Sign user logs in to OneSpan Sign via an Identity Provider, and auto-provisioning is disabled for them (allowSenderCreation=false), an error message appears which states that the user does not exist.

This error message highlights the need for a user in this situation to have someone: (1) enable auto-provisioning for them; (2) perform one of the Auto-Provisioning Enabled procedures for them.

We recommend that you specify the attributes accountid and role in your Identity Provider's settings. If you don't do this, auto-provisioning will work as follows:

  • If the Entity Id is shared by multiple accounts, an Unauthorized Access error will be returned.

  • If the Entity Id is not shared by multiple accounts, the new user must be added — auto-provisioned — to the OneSpan Sign account that holds the SAML configuration (this configuration typically resides in the main account, Level 0). After you have auto-provisioned the new user, you must assign them a role. If you don't do this, the user will not be able to create any transactions.

Already a OneSpan Sign User

When someone who is already a OneSpan Sign user logs in to OneSpan Sign via an Identity Provider:

  • They are automatically redirected to the Dashboard.

  • The system ignores the allowSenderCreation parameter.

Microsoft's Active Directory Federation Services (ADFS) can serve as a SAML 2.0 Identity Provider for OneSpan Sign.

To configure ADFS to serve as a SAML Identity Provider for OneSpan Sign:

  1. Start the ADFS 2.0 Management Console.
  2. Open the Trust Relationships folder, and right-click Relying Party Trusts.
  3. Select Add Relying Party Trust, and then Start.
  4. In the Add Relying Party Trust wizard, select Import data about the relying party from a file.
  5. Import the required metadata into your keystore. To download it, see Updating your SAML Certificate and Metadata.
  6. Complete the wizard as necessary, entering your Display Name, and the Authorization Rules you want to use.
  7. On the Advanced tab, change the Secure hash algorithm to SHA-256.
  8. Create new Claims Rule for LDAP Attributes using the following template:

  9. Edit the rule so your screen looks as follows:
  10. Create another Claims Rule to Transform an Incoming Claim. This will add email to the Subject of the response as NameID.

  11. This Claim Rule will reference the first Claim Rule. For this reason, the latter must remain Rule 1.

OKTA can serve as a SAML Identity Provider for OneSpan Sign.

The following example configures OKTA as the Identity Provider for a OneSpan Sign US Sandbox instance.

To configure OKTA to serve as a SAML Identity Provider for OneSpan Sign:

  1. Navigate to https://www.okta.com/developer/signup/, and create a free OKTA Developer Edition organization.
  2. Log in to the Admin Console, and click Add Applications.
  3. Click Create New App, and select SAML 2.0 as the Sign On Method.
  4. In the General Settings section, enter an App name. Then click Next.
  5. In the Configure SAML section, paste the following URL into the Single sign on URL fields:
  6. https://sandbox.e-signlive.com/sso/saml/SSO/alias/e-signlive

Keep the recipient URL and destination URL the same.

  1. In the Audience Restriction field, enter the SP entity ID. For example: urn:saml:sso:sandbox:e-signlive:com.
  2. For the default relay state value, enter https://sandbox.e-signlive.com/packages/inbox
  3. Click Show Advanced Settings, and configure the settings in the following table:
  4. SETTING VALUE

    Name ID format

    EmailAddress

    Response

    Signed

    Assertion Signature

    Unsigned

    Signature Algorithm

    RSA_SHA256

    Digest Algorithm

    SHA256

    Assertion Encryption

    Unencrypted

    SAML Single Logout

    Disabled

    authContextClassRef

    Unspecified

    Honor Force Authentication

    No

    SAML Issuer ID

    http://www.okta.com/${org.externalKey}

  1. In the Attribute Statements section, add the following three attribute statements, and then click Next:
  2. Name Name Format Value
    email URI Reference user.email
    firstname URI Reference user.FirstName
    lastname URI Reference user.lastName
  3. In the Feedback section, select This is an internal application that we created. Then click Finish.

    You will now see the Sign On section of your newly created Example SAML Application. Keep this page open in a separate browser tab or window. You will need its Identity Provider metadata link when you perform the procedure Configuring SAML on Your eSignLive Account.

  4. To copy the Identity Provider metadata link, right-click it and select Copy.

  5. Right-click the People section of the Name of your application, and select Open Link In New Tab (so you can come back to the Sign On section later).
  6. In the new tab that opens, click the Assign Application button.
  7. A dialog box called Assign name of Application to up to 500 people appears. Type your username in the search box, and select the check box next to your username. Then click Next.
  8. You will be prompted to enter user-specific attributes. Click Confirm Assignments to keep the defaults.

    You are now ready to perform the procedure Configuring SAML on Your eSignLive Account. You will need the Identity Provider metadata link from Step 10.

Azure AD can serve as a SAML Identity Provider for OneSpan Sign. For more information on this, see the Microsoft Azure documentation.

To configure Azure to work with OneSpan Sign, you must perform the following procedures:

  1. Satisfying Prerequisites
  2. Adding OneSpan Sign as an Application to Azure AD
  3. Configuring Basic SAML Settings
  4. Configuring User Attributes & Claims
  5. Configuring Users & Permissions
  6. Testing the SP Initiated SSO

Prerequisites

To get started, you need the following items:

  • An Azure AD subscription
  • A OneSpan Sign account, either Sandbox or Production
  • The SAML Metadata that applies to your OneSpan Sign instance (e.g., sandbox.esignlive.com)
  • If you plan to use SP Initiated SSO, you must download the Federation Metadata XML file.

To download the Federation Metadata XML file:

  1. Sign in to the Azure portal as either a Cloud application admin, or as an application admin for your Azure AD tenant.
  2. Click Azure Active Directory.
  3. From the active directory, click Enterprise application, and then All Applications.
  4. Find the Manage section, and select Single sign-on.
  5. Select SAML.
  6. On the Set up single sign-on with SAML page, navigate to the SAML Signing Certificate section.
  7. Click the Federation Metadata Download link.
  8. Contact our Support Team, so we can complete the configurations needed on our end.

Adding OneSpan Sign as an Application to Azure AD

The first step in configuring Azure as a SAML provider for OneSpan Sign is to add OneSpan Sign to the Azure AD application portal.

To add OneSpan Sign to the Azure AD portal:

  1. Sign in to the Azure portal as either a Cloud application admin, or as an application admin for your Azure AD tenant.
  2. Click Azure Active Directory.
  3. Select Enterprise applications, and then click All Applications.
  4. Click New application, and then choose Non-gallery application.
  5. Enter a name for your application (e.g., OSS) , and then click Add.

Configuring Basic SAML Settings

Now you have added the app, you need to make some basic SAML configurations.

The settings you must configure will vary, depending on your OneSpan Sign instance, and on whether you will configure SSO to be IDP Initiated or SP Initiated.

To configure your SAML settings:

  1. Sign in to the Azure portal as either a Cloud application admin, or as an application admin for your Azure AD tenant.
  2. Click Azure Active Directory.
  3. From the active directory, click Enterprise application, and then choose the app you just added (e.g., OSS).
  4. Find the Manage section, and then select Single sign-on.
  5. Select SAML.
  6. On the Set up single sign-on with SAML page, click the edit icon in the Basic SAML Configuration section.
  7. Enter the following information:
    • Identifier (Entity ID): The Entity ID can be copied from the SAML Metadata you downloaded earlier. To find the Entity ID, open the metadata file using a text editor such as Notepad, and search for Entity ID. Once found, copy and paste the entry into this field.
    • Reply URL: The reply URL is your SSO service URL. For example, https://<your instance>/sso/saml/SSO/alias/e-signlive.
    • Sign on URL: This field is necessary only if you will use SP Initiated SSO. If you are using IDP Initiated SSO, leave this field blank. if you will use SP Initiated SSO, enter the following: https://<server:port>/sso/saml/login/alias/e-signlive?idp=<EntityId of an IdP>,
      where:
      • <server:port> is the server port used by your OneSpan Sign instance. For example, https://sandbox.esignlive.com.
      • <EntityId of an IdP> is the Entity ID found in the Federation Metadata XML file you downloaded earlier. To find the Entity ID, open the metadata file using a text editor such as Notepad, and search for Entity ID. Once found, copy and paste the entry into this section of the URL.

  8. If you are using SP Initiated SSO, contact our Support Team so we can complete the configurations that are needed on our end.

The following table contains more information about SAML's configuration settings:

SAML Configuration Setting SP-Initiated IDP-Initiated Description

Identifier (Entity ID)

Required for some apps

Required for some apps

Uniquely identifies the application. Azure AD sends the identifier to the application as the Audience parameter of the SAML token. The application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. You can find this value as the Issuer element in the AuthnRequest (SAML request) sent by the application.

Reply URL

Optional

Required

Specifies where the application expects to receive the SAML token. The reply URL is also referred to as the Assertion Consumer Service (ACS) URL. You can use the additional reply URL fields to specify multiple reply URLs. For example: (1) you might need additional reply URLs for multiple sub-domains; (2) for testing purposes, you can simultaneously specify multiple reply URLs (local host & public URLs).

Sign-on URL

Required

Don't specify

When a user opens this URL, the service provider redirects to Azure AD to authenticate the user and sign them on. Azure AD uses the URL to start the application from Office 365 or the Azure AD Access Panel. When blank, Azure AD performs IDP-Initiated sign-on if a user launches the application from Office 365, the Azure AD Access Panel, or the Azure AD SSO URL.

Relay State

Optional

Optional

Specifies to the application where to redirect the user after authentication is completed. Typically the value is a valid URL for the application. However, some applications use this field differently. For more information, ask the application vendor.

Logout URL

Optional

Optional

Used to send the SAML Logout responses back to the application.

Once completed, your Basic SAML Configuration should look something like this, with the values in each field representing values from your own site. For example, in the following image you must replace sandbox.esignlive.com with the domain name from your own SSO service URL:

Configuring User Attributes & Claims

Once your Basic SAML Settings have been configured, you can begin creating associations between a user and their attributes.

To configure user attributes and claims:

  1. Click Azure Active Directory.

  2. From the active directory, click Enterprise application, and then choose the app you just added (e.g., OSS).
  3. On the Set up single sign-on with SAML page, click the edit icon in the User Attributes section.
  4. Delete any existing attributes that appear.
  5. Click Add new claim.
  6. In the Name box, type the attribute name.
  7. Leave the Namespace field blank.
  8. Add the following claims in the Source Attribute field, mapping the claim name and source attributes as follows:
    Name OptionsSource Attribute

    firstname

    user.givenname

    email

    user.mail

    lastname

    user.surname
  9. Click Save.

Automatic Provisioning

If you have the same SAML configured in multiple accounts across the same instance, you will need to add an additional attribute to automatically provision new senders to a specific account. If you fail to do so, automatic provisioning will fail.

The name of the required attribute is accountid. It can be mapped to any Azure Ad attributes that have the destination account UID (for the list of your account UIDs, contact our Support Team).

  • accountid: This claim should be mapped to an active directory attribute that contains the owner account's accountID.

  • type: This claim should be mapped to an active directory attribute that is either a Regular value or a Manager value.

Configuring Users & Permissions

Now that you've defined some user attributes and claims, you can begin to assign users to the app.

To configure user permissions:

  1. Click Azure Active Directory.

  2. From the active directory, click Enterprise application, and then choose the app you just added (e.g., OSS).
  3. Click Users and Groups.
  4. Click Add user.
  5. In the Add Assignment section, select Users and Groups.
  6. Select the user or group you want to assign to use the application.
  7. Click Select.

Testing the SP Initiated SSO

Now that you've finished your configurations, you can test to see that everything works.

To test the SP Initiated SSO:

  1. Sign in to the Azure portal as either a Cloud application admin, or as an application admin for your Azure AD tenant.
  2. Click Azure Active Directory.
  3. From the active directory, click Enterprise application, and then choose the app you just added (e.g., OSS).
  4. Find the Manage section, and then select Single sign-on.
  5. In the Test Single Sign On section, click Test.
  6. Click Sign in as current user.