SSO Integration Guide
SSO (single sign-on) is an optional feature that allows users to log in to your Sona site using their university credentials, so they do not need to remember a username and password just to use their Sona site. If the university’s IDP is listed in eduGAIN, there is no additional charge for this feature.
When you are ready to get started, simply fill out the SSO Configuration form and email it to us.
How It Works
With SSO, users can log in using their university username and password. When they go to the front page of their Sona site, they will see an option to log in using SSO.
If they click on the SSO Log In button, they will be taken to their university site to log in, and then redirected back to their Sona site. Depending on how you choose to configure SSO, the option to log in using a username/password set up in Sona may still be there – this is useful if you have some users from outside the university community.
For participants in the university community who do not have an account on your Sona site, they can click on SSO Log In to authenticate with SSO, then the Request Account page on your Sona site will have their name and email address already completed, and they only need to fill in additional information like course enrollment.
SSO is used solely to authenticate the user. In other words, it is used to identify who they are, but not what courses they are in, or what role they have at the university. Course enrollment and roles are set up on the Sona side.
For user accounts already on your Sona site before SSO was enabled, if their email address in SSO matches the email account of a non-SSO account already in the system, then it will be converted to an SSO account (with all data preserved) automatically the first time they try to log in with SSO. Note that if @ Suffix is currently enabled on your site, and users have entered an alternate email address for their account, this email address will be removed when we enable SSO on your site, so that the system can properly match up accounts based on university email address.
You can also convert any account to SSO manually in User Management when you go to edit the user’s account. You’ll just need to know their SSO ID, which is often the same as their university email address.
Note if you import user accounts, and retain past user accounts, and SSO is required, then you will need to be careful about duplicate accounts, particularly if you go live with SSO at the start of the semester. What can happen is the newly-imported accounts are SSO, while the existing accounts are non-SSO (pending the user logging in and it converting to SSO). The best solution is to do the usual user import just before going live with SSO, so they will import as non-SSO accounts and convert upon their first login to SSO.
Technical Information
Our SSO environment utilizes Shibboleth in the Service Provider (SP) role, to ensure that we are 100% SAML2 compliant. Our entities are listed in eduGAIN, InCommon, TAAT, and UK Access Management Federation. Our registrar (federation) is TAAT. We are listed as a Research & Scholarship Entity through REFEDS.
We require that your IDP is listed in the eduGAIN directory. If you are a member of InCommon Federation but not listed in eduGAIN, you just need to turn on the eduGAIN export option in Federation Manager on InCommon. If you have any questions, please email us and include the URL of the Sona site you are referring to.
Attribute Release
In terms of attributes to release, we require only the Research & Scholarship bundle, specifically:
● eduPersonPrincipalName (urn:mace:dir:attribute-def:eduPersonPrincipalName, urn:oid:1.3.6.1.4.1.5923.1.1.1.6 )
● mail (urn:mace:dir:attribute-def:mail, urn:oid:0.9.2342.19200300.100.1.3)
● givenName (urn:mace:dir:attribute-def:givenName, urn:oid:2.5.4.42)
● sn (urn:mace:dir:attribute-def:sn, urn:oid:2.5.4.4)
According to the specification, mail, givenName, and sn may contain more than one value. In such cases, our system will use only the first value for each.
Our system manages access control, and we rely on SSO solely for authentication, so in most cases you can just release this set of attributes for any user in your directory who authenticates. There is not a need to set up rules so that only those in certain departments or with certain roles may authenticate.
Entity IDs
We have servers in multiple regions, but you only need to configure your IDP for the one SP that is in your region, not all four SPs. Our Entity IDs are as follows:
Customers in all of North America and South America, except Canada:
Entity ID: https://sso-usa.sona-systems.com/shibboleth
Metadata
Customers in Canada:
Entity ID: https://sso-canada.sona-systems.com/shibboleth
Metadata
Customers in Europe, Middle East, and Africa:
Entity ID: https://sso-europe.sona-systems.com/shibboleth
Metadata
Customers in Asia/Pacific:
Entity ID: https://sso-asia.sona-systems.com/shibboleth
Metadata