SAML2 | An acronym for "Security Assertion Markup Language 2.0", which is the standard implemented by AD FS and Shibboleth to allow integration with applications (such as Chorus). |
|---|
Identity Provider (IdP) | The third party service used by Chorus (as a Service Provider) to authenticate a user. This is provided by either your AD FS or Shibboleth service. |
|---|
Service Provider (SP) | The part of Chorus which requests authentication from the IdP. |
|---|
Relying Party (RP) | The application that is using the SP and IdP to authenticate, in this case Chorus. |
|---|
Entity ID | The unique ID of the IdP or SP. Normally it looks like a URL, but it is not necessary for the Entity ID to be resolvable. |
|---|
Metadata | The details of the IdP or SP. If Third Light can connect to the IdP (and vice-versa) you can use the URL and this enables automatic lookup of the metadata. Otherwise, you will have to manually supply the metadata. |
|---|
Name ID | This is the primary data returned when Chorus completes authentication with the IdP. |
|---|
Attributes | Attributes are pieces of data about the user who has been authenticated by the IdP. This allows Chorus to know who has been authenticated and to which group the user belongs. |
|---|
SAML2 Visible Groups | The SAML2 groups selected from the SSO provider will be available for use in Chorus spaces. This allows you to add specific SAML2 groups to Chorus as SAML2 Groups can be assigned to roles in Spaces. For example, you could add a SAML2 Group for all of your marketing team to a Chorus "Marketing" Space's member role, then every user already in the SAML2 Group for Marketing will be able to see the Marketing Space in Chorus. |
|---|
Assertion Consumer Service (ACS) | The ACS URL is an endpoint on the service provider where the identity provider will redirect to with its authentication response. In Azure this is referred to a "Reply" URL, and in Okta this is referred to as an "SSO" URL. |
|---|
