dc1359a763
* providers/saml: initial SLO implementation Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * providers/saml: add logout request tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * providers/saml: add tests for POST SLO Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * matrix e2e tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix import Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * set e2e matrix name Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix imports Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * separate oidc and oauth tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add basic saml slo e2e tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add better metadata download url Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * kinda prepare release notes Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * sort releases into folders Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add slo urls to website Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix linking Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add api tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * update docs Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
2.5 KiB
2.5 KiB
| title |
|---|
| SAML Provider |
This provider allows you to integrate enterprise software using the SAML2 Protocol. It supports signed requests and uses Property Mappings to determine which fields are exposed and what values they return. This makes it possible to expose vendor-specific fields. Default fields are exposed through auto-generated Property Mappings, which are prefixed with "authentik default".
| Endpoint | URL |
|---|---|
| SSO (Redirect binding) | /application/saml/<application slug>/sso/binding/redirect/ |
| SSO (POST binding) | /application/saml/<application slug>/sso/binding/post/ |
| SSO (IdP-initiated login) | /application/saml/<application slug>/sso/binding/init/ |
| SLO (Redirect binding) | /application/saml/<application slug>/slo/binding/redirect/ |
| SLO (POST binding) | /application/saml/<application slug>/slo/binding/post/ |
| Metadata Download | /application/saml/<application slug>/metadata/ |
You can download the metadata through the Webinterface, this link might be handy if your software wants to download the metadata directly.
The metadata download link can also be copied with a button on the provider overview page.
Name ID
You can select a custom SAML Property Mapping after which the NameID field will be generated. If left default, the following checks are done:
- When the request asks for
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, the NameID will be set to the user's email address. - When the request asks for
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, the NameID will be set to the hashed user ID. - When the request asks for
urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName, the NameID will be set to the user'sdistinguishedNameattribute. This attribute is set by the LDAP source by default. If the attribute does not exist, it will fall back the persistent identifier. - When the request asks for
urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName, the NameID will be set to the user's UPN. This is also set by the LDAP source, and also falls back to the persistent identifier. - When the request asks for
urn:oasis:names:tc:SAML:2.0:nameid-format:transient, the NameID will be set based on the user's session ID.