How do we set up a SAML SSO login when a new employee needs access to the Widen Collective?
New employees can access the Collective based on their membership in your active directory group. When they’re included in that, new Collective accounts are created with just-in-time provisioning based on the user permissions in that group.
What are the attributes needed to identify the active directory required for our SSO to work?
Email address and first and last name attributes are required to be passed in the SAML assertion for every user that logs in via SSO. There are additional attributes that can be included.
Can user roles in the Collective be applied via SSO?
They can! Read more about sending roles via claims in our configuring a SAML SSO article.
What do you accept as a name ID attribute?
By default, we use the persistent name ID format, but unspecified and email address name ID formats can be configured within the Service Provider (SP) tab on the SAML Settings page in the Admin app of the Collective.
How is access to an SSO for an existing user modified in the Collective - say, if they change jobs and no longer need access?
Existing users’ permissions are modified within your active directory.
Can you tell me the process for a Service Provider-initiated login?
Sure! Here's how an SP-initiated login works:
The user accesses the Collective via a browser bookmark or from a link on their intranet. The Collective loads, placing this user on the login page. The user clicks on the IdP button, which performs a 302-redirect back to the identity provider to authenticate. (Subsequent logins will automatically redirect the user via a browser cookie.) The IdP login button can be added to the login page by request.
The user will either have an existing browser session with the identity provider or create a new browser session by logging in to the identity provider.
The identity provider then builds the SAML response in the form of an XML document that contains the user’s email address or username along with other supported attributes. This SAML response is signed using an X.509 certificate and the response is then posted back to the Collective.
The Collective verifies the response with the identity provider (using a public certificate you’ve uploaded to the site).
The identity of the user is verified by the Collective and the user account is created using just in time provisioning or the existing user is logged in to the Collective.
Note that IdP-initiated logins are similar but instead, the user would click on a Collective link within your portal or intranet.