SAML 2 / Shibboleth

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

  1. Install LocalistSAML 2/Shibboleth SP intoSAML 2/Shibboleth infrastructure.
  2. Provide IdP metadata.
  3. Localist installs IdP metadata for school instance.
  4. Test login ability and successful released attribute assignment.


  • If initially set up with placeholder domain (, 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.