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 Shibboleth page and will be passed through to the Localist system upon successful authentication.
Requirements from Organization
- School’s Shibboleth (IdP) metadata – It is preferred that URLs are provided so thatif 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 Shibboleth (SP) metadata.
Set Up Steps
- Install Localist Shibboleth SP into 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 (including 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.
If the Localist and/or Facebook login methods are allowed, then the Shibboleth login will appear as a button below the username/password fields for Localist accounts.
If 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 Shibboleth login page. The separate sign up functionality that is tied to the Localist login method will also disappear.