Contents
- Initial setup
- Customization on the login page
- After setup - connecting admin users
- Candidate setup
- Frequently Asked Questions (FAQ)
Initial setup
If you have SAML 2.0 as your Single Sign-On (SSO) method, the following steps provide information to assist in implementation.
Firstly, import/extract values from the Inspera metadata-file into your idp-solution when creating the ‘app’ Inspera Assessment. This metadata-file can be found at <yoursubdomain>.inspera.com/saml/metadata e.g. demo.inspera.com/saml/metadata.
You might need to adjust the claims/attributes for the SAML-assertion. The correct names for those attributes/assertions are inside the metadata file. By default, Inspera accepts the attribute eduPersonPrincipalName as externalUserId.
Inspera has the flexibility to utilize any distinct user attribute from the assertion. For example, you have the option to request that Inspera configure the SAML setup to utilize the attribute field where you typically store the email (urn:oid:0.9.2342.19200300.100.1.3 or mail). If you want to use another attribute than eduPersonPrincipalName as externalUserId, you need to inform your Onboarding Consultant or the Inspera Service Desk during the SAML setup.
Inspera also suggests that you include at least both names for the candidate users, as those are used to display the candidate names (givenName and sn) on the candidate dashboard and in the player, after they have logged into Inspera Assessment. If desired, candidate names can also be used to de-anonymize the candidates before the test or after the marking. Refer to the following articles for more information about de-anonymizing candidates:
Once you have imported Inspera’s metadata-file/extracted the needed values, provide your Onboarding Consultant or Service Desk with a weblink where your IDP-xml can be found. Inspera will use this to set up the integration on our end.
Customization on the login page
Once your Single Sign-On (SSO) integration is set up on Inspera’s end, a Generic SAML login-button will appear on your login page.
You are able to customize both the text in that button as well as add a logo. You can find the technical constraints specified in the article Customizations Within Inspera.
You may send Inspera your desired text and logo upon initial setup, or anytime after setup.
After setup - connecting admin users
To complete the Single Sign-On (SSO) setup for administrative users, login with your registered user credentials, go to User Administration and update the admin users within Inspera Assessment by entering the identifier/attribute you have set on your side into the SSO external userid text field.
The identifier is the value you have set in the attribute eduPersonPrincipalName. Inspera accepts urn:oid:1.3.6.1.4.1.5923.1.1.1.6 name or the friendly-name eduPersonPrincipleName as the default attribute-name for holding the externalUserId in the SAML response. This is unless you have requested a different attribute field in your setup.
Candidate setup
Inspera recommends that you have test students/candidates to test the Single Sign-On (SSO) setup on the candidate login page.
Candidates can be added on test level either by using CSV import or by using a test code. For more information on how to add candidates to tests, refer to the articles Candidate setup - CSV Import (SSO) and Assign learners by test code.
Frequently Asked Questions (FAQ)
Answer:
This usually means that you have not entered the SSO external userid in the corresponding Admin user’s profile as described in After setup - connecting Admin users. Follow the steps in that section and try logging in again.
If you still receive the error message, that usually means that the ID entered is incorrect. Please note that this field is case-sensitive.
Answer:
This typically means that the attributes are not mapped/set correctly in your active directory/SSO setup. Refer to your metafile e.g. <subdomain>.inspera.com/saml/metadata, you can see the attributes needed to pull through first name and last name:
These fields are case sensitive, so be careful of this i.e. givenname may also be set, but our file shows to use givenName, which is not the same. Same with surname and sn.
Answer:
The entityID is not a URL. Instead it is an ID-string that holds no value, so it is safe to use.