View the original community article here
Last Tested: May 16, 2019
There are several different identity providers (IdPs) that Looker supports in place of the regular email/password authentication system. An IdP stores identity information in one place, so that other websites can authenticate you without having to store your login information.
If you’ve used a “login with Google” button on a website, that’s Google acting as an IdP.
Types of IdPs Supported In Looker:
Looker currently supports 4 IdPs that are mutually exclusive; that is, you can only have one enabled at a time. The supported IdPs are:
- Google OAuth (also known as Google Auth or Google OAuth)
- SAML (Security Assertion Markup Language)
- LDAP (Lightweight Directory Access Protocol)
- OIDC (OpenID Connect aka OpenID OAuth)
They are all unique, but conceptually Looker interacts with all of them in the same way.
How do they work?
When using these authentication methods, Looker takes the information of the user attempting to log in, passes it to the identity provider, or IdP, who will attempt to authenticate the user. The identity provider will then pass back either a "Yes, we authenticate them and here's all their info" message or a "Nope, we don't know this person, don't let them in" message and Looker performs as instructed.
Why would I want this?
It’s true that Looker has a perfectly functional authentication system. However, there are several reasons a company might want to use an external authentication system (ex: security, customization, ease of use)
Sessions + IdPs
A common point of confusion is how closely tied the Looker instance and the IdP are. Is Looker constantly listening to the IdP, checking against it to make sure the user is valid?
No. Looker only authenticates once against the IdP, and then grants the user a Looker session.
This means that:
- Looker doesn’t store any authentication constructs like “SAML tokens”.
- Deleting a user from the IdP doesn’t remove them from Looker.
- If the IdP is unavailable, users logged into Looker stay logged in.
- It’s not possible for users to edit the session length from within their IdP.
Note that sessions that aren’t default login sessions will not be affected by enabling an IdP. These include:
- Logging in with API credentials
- Viewing a Public Look
- SSO Embed Links
Only one external authentication method can be used on an instance. That is, you can't have SAML and LDAP enabled at the same time.
However, if one of the four external authentication methods is enabled, then Looker provides a "back door" method to log into the instance, colloquially known as alternate login. Alternate login allows a user to use the default email-password authentication to log into the instance. This is convenient to prevent lockout situations or if you want to allow Looker access to someone not within your IdP.
A special permission "login_special_email" is required to use the alternate login page. The alternate login page is accessible via the "Alternate login page (email/password)" link from the regular login page.
This content is subject to limited support.