Many corporations may have an intranet or extranet dashboard that includes links to third-party services that may need user authentication. As Acquia DAM admin, you may want to leverage an existing IdP, or identity provider, to grant a single sign-on (SSO) experience to those third-party, web-based apps. We refer to your company’s software as an IdP.
There are several enterprise-level standards for federated identity, notably Security Assertion Markup Language (SAML), that can be used to provide an SSO. We recommend and prefer that the SAML version 2.0 web browser SSO profile be used to implement SSOs for Acquia DAM; however, many organizations may have not yet adopted a federated identity solution.
This article details a method for one-way authentication from any system that implements individual authenticated users. We refer to this system as the simple one-way SSO. If the IdP tracks only groups or roles of users (e.g., users authenticate using a generic group name, like sales or exec), this method cannot be used.
The method described has been designed primarily for ease of implementation and follows several best-practice data security policies.
Overview
The simple one-way SSO implementation depends on the ability of the IdP to generate HTML form markup on the server. The method described below cannot be used to generate markup via client-side JavaScript due to the usage of a shared secret key in signature calculation. This shared key is secret and cannot be shared externally, but it can be requested from your customer success manager. The implementation process is accomplished by the following:
- The IdP compiles user fields that will be sent to the DAM.
- These user fields, including the secret key, are used to generate a hash. The hash value is added to the list of user fields as the signature field.
- A request is constructed and sent to the DAM with the user fields and signature.
- The DAM verifies the request by recreating the signature value and comparing it to the signature value sent in the request. If all checks are passed, the user is logged in to the DAM.
Technical details
Get information on how to implement our simple one-way SSO at https://widensimpleonewaysso.docs.apiary.io/.
Code examples
See fully functional example apps written in Java, Node.js, and more that leverage our simple one-way SSO at https://github.com/Widen/widen-sso-examples.
How do I configure a simple one-way SSO?
Many corporations may have an intranet or extranet dashboard that includes links to third-party services that may need user authentication. As Acquia DAM admin, you may want to leverage an existing IdP, or identity provider, to grant a single sign-on (SSO) experience to those third-party, web-based apps. We refer to your company’s software as an IdP.
There are several enterprise-level standards for federated identity, notably Security Assertion Markup Language (SAML), that can be used to provide an SSO. We recommend and prefer that the SAML version 2.0 web browser SSO profile be used to implement SSOs for Acquia DAM; however, many organizations may have not yet adopted a federated identity solution.
This article details a method for one-way authentication from any system that implements individual authenticated users. We refer to this system as the simple one-way SSO. If the IdP tracks only groups or roles of users (e.g., users authenticate using a generic group name, like sales or exec), this method cannot be used.
The method described has been designed primarily for ease of implementation and follows several best-practice data security policies.
Overview
The simple one-way SSO implementation depends on the ability of the IdP to generate HTML form markup on the server. The method described below cannot be used to generate markup via client-side JavaScript due to the usage of a shared secret key in signature calculation. This shared key is secret and cannot be shared externally, but it can be requested from your customer success manager. The implementation process is accomplished by the following:
- The IdP compiles user fields that will be sent to the DAM.
- These user fields, including the secret key, are used to generate a hash. The hash value is added to the list of user fields as the signature field.
- A request is constructed and sent to the DAM with the user fields and signature.
- The DAM verifies the request by recreating the signature value and comparing it to the signature value sent in the request. If all checks are passed, the user is logged in to the DAM.
Technical details
Get information on how to implement our simple one-way SSO at https://widensimpleonewaysso.docs.apiary.io/.
Code examples
See fully functional example apps written in Java, Node.js, and more that leverage our simple one-way SSO at https://github.com/Widen/widen-sso-examples.
Acquia DAM