Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
72:integration:saml [2019/03/13 12:29] – emr | 72:integration:saml [2020/03/17 09:49] – [Validated IdP Vendors] etea | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Configure SAML Authentication ====== | ====== Configure SAML Authentication ====== | ||
+ | |||
+ | [[: | ||
SAML stands for Security Assertion Markup Language. It is a current standard for authenticating users in a distributed system. | SAML stands for Security Assertion Markup Language. It is a current standard for authenticating users in a distributed system. | ||
Line 40: | Line 42: | ||
< | < | ||
providerId="< | providerId="< | ||
- | signatureKeyAlias=" | + | signatureKeyAlias=" |
- | > | + | |
</ | </ | ||
Line 61: | Line 63: | ||
* EntityIdfromMetadata | * EntityIdfromMetadata | ||
+ | |||
* SingleSignOnServiceLocationFromMetadata | * SingleSignOnServiceLocationFromMetadata | ||
+ | |||
* DisplayName (alternative: | * DisplayName (alternative: | ||
+ | |||
* EMailAddress | * EMailAddress | ||
Line 76: | Line 81: | ||
nameIdPolicyFormat=" | nameIdPolicyFormat=" | ||
userFullnameTemplate=" | userFullnameTemplate=" | ||
- | | + | |
+ | <!-- userFullnameTemplate is used to build the user's full name from multiple IDP attributes | ||
+ | as defined below as < | ||
+ | In the example above the firstname and lastname attributes are concatenated speparated by a space. --> | ||
<!-- hardcoded magic value that specifies the NameID from the SAML reply --> | <!-- hardcoded magic value that specifies the NameID from the SAML reply --> | ||
< | < | ||
Line 137: | Line 146: | ||
< | < | ||
</ | </ | ||
+ | |||
</ | </ | ||
After you configured the service provider and identity provider in '' | After you configured the service provider and identity provider in '' | ||
+ | |||
===== Generate the SAML SP metadata ===== | ===== Generate the SAML SP metadata ===== | ||
Line 146: | Line 157: | ||
The resulting XML file can be sent to the SAML IdP administrators and contains all information necessary to set up the trust relationship on the IdP side. After the SAML IdP has been configured with the SP metadata, users will be able to authenticate successfully with Stages through the SAML IdP. | The resulting XML file can be sent to the SAML IdP administrators and contains all information necessary to set up the trust relationship on the IdP side. After the SAML IdP has been configured with the SP metadata, users will be able to authenticate successfully with Stages through the SAML IdP. | ||
+ | |||
+ | ===== Configure the SAML Request Type ===== | ||
+ | |||
+ | The default binding type of the SAML Request is '' | ||
+ | |||
+ | Some IDPs do not work with that type and rather need a POST Request. This can only be found out on the IDP. | ||
+ | |||
+ | This can be configured in the '' | ||
+ | |||
+ | < | ||
+ | sendBinding=" | ||
+ | </ | ||
===== Validated IdP Vendors ===== | ===== Validated IdP Vendors ===== | ||
Line 152: | Line 175: | ||
* Cisco Central Web Authentication (CWA) | * Cisco Central Web Authentication (CWA) | ||
+ | |||
* Oracle Access Manager (OAM) | * Oracle Access Manager (OAM) | ||
+ | |||
* Shibboleth IdP | * Shibboleth IdP | ||
+ | * Active Directory Federation Services (ADFS) | ||
Please let us know if you were able to make Stages SAML work with your server and it is not on this list yet. | Please let us know if you were able to make Stages SAML work with your server and it is not on this list yet. | ||