SAML 2/Shibboleth is set up with a metadata swap, which requires our development team to work directly with campus IT to configure the technical information. Each user will login from a campus-hosted SAML 2/Shibboleth page and will be passed through to the Localist system upon successful authentication.
Requirements from Organization
- School’s SAML 2/Shibboleth (IdP) metadata – It is preferred that URLs are provided so that if it ever changes, it will automatically update.
- User attributes released: email address, name (cn).
- Final domain name (domain does not need to be live)
- SSL certificate for final domain name (Can be added later)
Provided by Localist:
- Localist’s SAML 2/Shibboleth (SP) metadata.
Set Up Steps
- Install LocalistSAML 2/Shibboleth SP intoSAML 2/Shibboleth infrastructure.
- Provide IdP metadata.
- Localist installs IdP metadata for school instance.
- Test login ability and successful released attribute assignment.
- If initially set up with placeholder domain (school.localist.com), updated SP metadata will be provided with the final domain name.
- Only SAML 2.0 is supported (includingSAML 2/Shibboleth)
- If your school’s website is being served over SSL, to avoid some browser warnings, a SSL certificate may be required to enable SSL for Localist.
Using SAML 2/Shibboleth
If the Localist and/or Facebook login methods are allowed, then theSAML 2/Shibboleth login will appear as a button below the username/password fields for Localist accounts.
If SAML 2/Shibboleth is the only method allowed, then the login modal will not be displayed. Instead, the login link will be linked with directly with your SAML 2/Shibboleth login page. The separate sign up functionality that is tied to the Localist login method will also disappear.