Q: What value should the nameID be?
A: The user’s primary email address. This email address must also be the same email address used when the user’s account was created in Core.
Q: Is it possible to bypass SSO?
A: Yes. Users can be flagged to bypass the SSO authentication strategy, which then enables a user to log in using the default username and password strategy.
Q: Is there multiple domain support?
A: Yes. Multiple domains can be configured for SSO (e.g., somedomain.com,somedomain.sub.com).
Q: Are there any other data items we can send in the SAML token, such as name, phone, country, location, etc?
Q: Does Core support real-time new user provisioning based on SAML requests?
Q: We’re using ADFS as the IdP. What claim should be configured?
A: Claims should be configured as follows:
Claim Rule: Template: "Send LDAP Attributes as Claims"
Attribute Store: Active Directory
LDAP Attribute: The Attribute that contains the User email addresses set up in Core (typically the User Principal Name, but not always)
Outgoing Claim Type: Name ID
Q: Where can I find the Single Sign On URL (Assertion Consumer Service)?
A: The Single Sign On URL can be found in the SP metadata provided by Resolver for the specified environment.
Q: Where can I find the Recipient URL and Destination URL?
A: The Recipient and Destination URL can be the same as the Single Sign On URL, which can be found in the SP metadata.
Q: Where can I find the Audience URI?
A: The Audience URI or EntityID can be found in the SP metadata provided by Resolver for the specified environment.
Q: What value should the Audience be?
A: The Audience value should be the EntityID provided in the metadata (see
Q: What Value should the Recipient be?
A: The Recipient value should be provided in the the SP metadata file (see
Q: What value should the ACS be?
A: The ACS value should also be provided in the the SP metadata file (see
Q: What value should the Certificate be?
A: The Certificate is provided in the SP metadata file (see