Single Sign On Configuration

Overview

Asignet supports Single Sign-On (SSO) with most providers through Security Assertion Markup Language 2.0 (SAML 2.0). SAML 2.0 is an open federation standard that allows an Identity Provider (IdP) to authenticate users and pass identity and security information about them to a Service Provider (SP), typically an application or service. In this case, SP is the Asignet application.

Asignet has integrated clients through SAML 2.0 with different providers like Azure AD, Okta, and PingFederate.

Both forms of authentication are supported: Identity Provider Initiated (IdP-Initiated) or Service Provider Initiated (SP-Initiated).

High Level Steps

Asignet to get in touch with the Client tech team managing their authentication providers and agree on the configuration both parties can support for SSO. Preferably through SAML 2.0 with Identity Provider (almost always easier to implement).

Asignet to ask Client about their SSO method and Identity Provider.

Asignet to supply the SSO configuration.

Client to configure the Identity Provider.

Asignet to integrate the Service Provider.

Client to provide users to test SSO.

Asignet to make any updates or adjustments for SSO.

Asignet to maintain valid certificate to decrypt assertions (typically once a year).

SSO Configuration

Perform the following instructions to set up SSO through SAML 2.0.

Basic Identity Provider SAML Configuration

Client should get the basic values from Asignet for their IdP. The required configuration settings are:

· Identifier (Entity ID): Uniquely identifies the Asignet application against the IdP.

· Assertion Consumer Service (ACS / Reply URL): Specifies where the Asignet application expects to receive the SAML token.

· Service Provider Login URL (Sign on URL): When a user opens the URL, the Asignet application redirects to IdP to authenticate and sign on the user. This is only needed for SP-Initiated logins.

· Relay State: The IdP sends the browser to this URL after user authentication. This is optional and almost never used.

· Logout URL: The SP sends the browser to this URL when the user clicks on the SP logout button. This is optional.

Client to configure IdP application with the following values.

Note: The reference for <client> should be replaced with the actual name of client.

Configuration Setting	Value
Identifier (Entity ID)	https://<client>.asignet.com/
Assertion Consumer Service (ACS / Reply URL)	https://<client>.asignet.com/sso.ashx
Service Provider Login URL (Sign on URL)	https://<client>.asignet.com/saml/auth
Relay State	This is optional and almost never used.
Logout URL	This is optional. https://<client>.asignet.com/sso.ashx?logout=1

User Attributes and Claims

When a user authenticates to the Asignet application, the IdP issues the application a SAML token with information (or claims) about the user that uniquely identifies them. Make sure the user attributes and claims correspond.

At the minimum, this information should include the user network name/employeeID or email address.

Field Name	Value
NameID	user network name/employeeID or email address

Asignet Application Integration

Once the IdP is configured, Asignet needs the following values to finish the configuration in the SP SAML consumer:

· SAML Endpoint URL: Works as the EntityID in the IdP setup. It needs to be the set to the same value on both sides (IdP and SP configurations), so the assertion source is identified. For example, https://login.identityprovider.com/xyz/saml2 .

· SAML Signing Certificate: Client to provide the SAML signing certificate in file or string format, or the URL to download the federation metadata where Asignet can extract the certificate from. The IdP uses a certificate to sign the SAML tokens to the application. This certificate is required to configure and validate the trust between IdP and the Asignet application.