Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials. For Agreement Express this means a customer could click a button in their own application and be automatically logged into Agreement Express.
How’s This Done?
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
An Identity Provider (IDP) is a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying party applications.
A Service Provider (SP) is a system entity that receives and accepts authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML).
Agreement Express supports both IDP or SP initiated SSO; In both cases, Agreement Express acts as a SP. The unique user identifier for the Agreement Express is the email address that should be provided in the SAML assertion.
What is required to set SSO?
Usual steps are:
An Agreement Express system administrator sets/creates a company on the Agreement Express website
Special metadata is exchanged with an Identity Provider (IDP). Agreement Express acts as a Service Provider (SP).
Agreement Express is configured to use metadata obtained from the IDP.
Some work is required on the IDP side:
IDP uses metadata from Agreement Express to configure their infrastructure.
If IDP wants to support IDP initiated SSO, IDP has to create a link or otherwise request access to a protected SP resource; typically, the IDP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. Then the browser automatically posts the HTML form back to the SP.
In some cases additional coding and application changes are required to process the extra data from the assertion (i.e. api keys, product list, special access codes etc.) .
Does the application support SAML 2.0?
All products supporting SAML 2.0 in Identity Provider mode (e.g. Active Directory Federation Services (ADFS), Okta, Shibboleth, OpenAM, Efecte EIM or Ping Federate) can be used to connect with the application.
Is the application capable of ADFS ID and App ID link to the same Profile?
The Agreement Express application’s unique user ID is an email address. It is not possible to group ids under the same profile. That said, it depends on the ID provider whether the different profiles on their side will send the same email address in the assertion.
What attributes are required?
The unique user id in Agreement Express is the email address.
Therefore, an attribute with name mail or email or a claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress is required
What attributes are possible?
The application can receive any attribute, but they will be ignored unless the application is modified to do something with them.
Can the application accept the employee ID as a unique identifier?
Does the application provide a separate URL for external access?
A user can login through SAML federation or through the main login page. In some implementations, the assertion obtained with SSO contains some extra information (api key, product list, etc.) that might not be available to Agreement Express by a manual login.
Is there a QA environment available for testing?
Yes SSO can be set up with with Staging and UAT as well as Production servers.
What's the average timeframe for an SSO integration?
Work will need to be scheduled into a Sprint as there are code changes required (minimal for a typical configuration). Implementation will take longer if the customized SAML assertion processing is required.
What is a SAML metadata document?
The SAML metadata standard belongs to the family of XML-based standards known as theSecurity Assertion Markup Language (SAML).
A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability. In any case, at least the following metadata must be shared:
Protocol Endpoints (bindings and locations)
Systems like ADFS, Okta, Salesforce, or SimpleSAMLphp can produce metadata automatically.
Can login access be restricted to SSO?
Yes. By default users can log in directly into AEX or go through SSO. To restrict access use company setup SSO_LOGIN_ONLY with values:
1: All Publishers must log in through SSO
2: All Publishers and Company Admins must log in through SSO
What happens if a customer has multiple companies set up in AEX? Which company would SSO direct them to?
SSO follows the same logic as when an user logs directly into AEX.