Single Sign On
Out of the box, Localist provides its own local account creation and log-in feature as well as the ability to sign in with Facebook, Twitter, Google and LinkedIn.
In this article you will find:
- Features a User Can Access When Logged In
- Creating An Account
- Customizing Social Log-ins
- Shibboleth/SAML 2
Features a User Can Access When Logged In
- I’m Interested
- Add photos to an event
- Submit an event
- Follow a group
- Follow a place
- Invite Friends
Creating An Account
On your calendar homepage you will see Sign Up and Login links at the top of the page. Select Sign Up.
Localist’s account creation has a very low barrier to entry and only requires name + email address. If your platform has social logins, then users will also be prompted on this page to use these services.
Once an account is created, you can Login on the calendar homepage.
Customizing Social Log-ins
1. Navigate to Settings > Global Options in your admin dashboard*
2. To remove a social login, just simply uncheck the option
3. Save Changes
- You must be a Platform Admin to modify this setting.
CAS can be set up using three specific URLs provided by your IT department:
- Callback URL
- Validate URL
- Logout URL
We require a name and email address in order to create the user’s record on our end. CAS doesn’t support sending these extra attributes by default, but we do support a common extension of including the name and email in a cas:attributes section of the response. If your system doesn’t support this, the first time a user logs into Localist we will prompt them for this information.
If the Localist and/or social login methods are allowed, then the CAS login will appear as a button below the username/password fields for Localist accounts.
If CAS is the only method allowed, then the login modal will not be displayed. Instead, the login link will be linked with directly with your CAS login page. The separate sign up functionality that is tied to the Localist login method will also disappear.
To authenticate a user against an LDAP source, we first connect to the LDAP server using the provided bind account. A search is then performed to find an entry with the entered username in the specified search field. If an entry is found, we then take the details returned and attempt to reconnect to the server with that account using the entered password. If this is accepted, the entered credentials are valid.
Requirements from Organization
1.LDAP server name and port (we support normal LDAP over port 389 and LDAP over SSL on port 636)
3.Attribute to search for entered username (mail, sAMAccountName, etc.)
4.A bind account to be able to execute the above search
5.The user’s name (at least one of sn+givenname, displayname, cn, or name attributes) and e-mail address (mail attribute) should be available after binding as the user.Server address ranges will be provided if necessary for firewall configuration.
- AD domain (if using Active Directory)
- Server address ranges will be provided if necessary for firewall configuration.
With LDAP, users will select the Login link on the calendar homepage and sign in directly in the login modal. If other login options are available then they will be listed below (see Login with Facebook below). Note: It is not possible to use LDAP + Localist account logins.
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 (school.enterprise.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.