Troubleshooting SSO Configuration
When setting up the SSO configuration in ADFS, I am seeing a relying party trust error.
Older versions of ADFS have been known to display errors with relying party trust identifiers. The errors displayed are usually:
- MSIS3055: The requested relying party trust 'https://app.novoed.com/saml/metadata' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust.
- MSIS3020: The relying party trust with identifier 'https://app.novoed.com/saml/metadata' could not be located.
A recommended workaround would be for the IT Team to manually add a second relying party trust identifier.
- https://app.novoed.com/saml/metadata?provider=xxxx is usually already set up by the client using our metadata URL.
- https://app.novoed.com/saml/metadata is the second relying party trust identifier that can be added.
Here is an article from Microsoft on how to create a relying party trust: Create a Relying Party Trust.
I am directed to my identity provider's login page. When I enter my credentials on this page, I see the error message, "AADSTS50105: [User] is not assigned to a role for the application."
If the identity provider's page is presenting an error, this typically indicates that your IT Team needs to adjust their configuration. The IT Team should check that you are added to the list of users approved to use SSO to log into NovoEd.
I am directed to my identity provider's login page. When I enter my credentials on this page, I receive a NovoEd error page showing the message, "The request is not what we expected."
This typically indicates that your identity provider is sending NovoEd a GET request for Assertion Consumer Service. Please notify your IT Team that the SSO configuration should be updated to sending NovoEd a POST call instead.
I am directed to my identity provider's login page. When I enter my credentials on this page, I receive a NovoEd error page showing the message, "We could not locate what you were looking for."
Typically, this means that attribute mapping is not matching the attributes (First Name, Last Name, Email, External ID) configured in NovoEd. This may also mean that the certificate that has signed the SAML response does not match what is configured in NovoEd. Please contact NovoEd Support and share a HAR file capturing your browser's attempt to access the SP-init URL. (Related Article: How to Capture a HAR file and Screenshot Your Console)
How can I stop users from changing their names?
An Org Admin can prevent users' ability to change their names. To prevent users from updating their names, follow the directions below:
- Access the Org Admin dashboard.
- Select the Settings gear icon on the left-hand panel.
- In the SSO User Account Settings section, select the box Prevent SSO users from modifying name in NovoEd Account Settings.
What is the benefit of including an External ID in the SSO configuration?
Mapping an External ID gives NovoEd an additional data point to authenticate a user's account. In the event that a user's email address may change, NovoEd can rely on the External ID to confirm the user's identity and the user's email address will be updated.
Please ensure that the attribute set up as the External ID is indeed being sent for your users. The attribute can be mapped. However, it is not required that it is received by NovoEd for each user.
What happens if an External ID is not included in the SSO configuration?
If an External ID is not included in the SSO configuration, then users entering NovoEd with a changed email address will have a duplicated account. The duplicated account may count toward licensing. Additionally, accounts cannot be merged, so completion progress made in both accounts will remain separated.