DANIEL KANE: Hello, everyone.
And welcome to this "Chrome On Air" webinar on Single Sign
On Identity and Access.
My name is Daniel Kane.
I'm a Partner Success Engineer at Google.
And if you're listening live and have any questions,
please submit them below, and we'll
do our best to answer them during the session.
The agenda for this webinar is as follows.
I will give a quick introduction to the different identity
options available on Chrome OS.
We will look at SAML SSO in more detail,
outlining the architecture and authentication flow,
and stepping through configuring SAML SSO on the Google Admin
Console.
To wrap up, we will look at some watchpoints
to keep in mind when deploying Chrome Enterprise with SAML SSO
and quickly touch on some upcoming improvements
to the implementation.
Chrome Enterprise provides a number
of different options for businesses
to authenticate their users onto Chrome OS devices.
The first option is using Google Identity.
If the customer has already deployed Google Identity,
either to use G Suite or other Google Cloud Services,
then these same credentials can be
used to log into Chromebooks.
And this is an ideal solution for customers who have already
moved to the Cloud.
Often, customers will continue to use an existing Active
Directory or AD/LDAP service as a source of truth for user
details, and will sync identities
to Google Identity using Google Cloud Directory Sync.
When using Google Identity, passwords
are stored in the Cloud, and customers
have the option of leveraging Google's two-step verification
solution.
The next option customers have is
to use federated login, specifically,
SAML Single Sign On.
This is, by far, the most common scenario
we encounter in working with large businesses
and in education.
With this setup, Google Cloud Directory Sync
is commonly used to sync identities
from the identity provider to Google.
However, passwords are managed at the identity provider
and not by Google Identity.
One nice benefit of this configuration
is that, once authenticated, the user
has a SAML cookie on their device, which
can be used to automatically log them
into other services which are using the same identity
solution.
Another option available to enterprise customers
is Direct Microsoft Active Directory integration.
With this setup, the user authenticates
with their Active Directory username and password.
The entered credentials are checked directly against AD.
There is no need for a SAML identity provider
to be configured.
We usually see customers opting for this solution
during Chrome pilots and testing.
In production environments, we would
encourage customers to move towards a Federation,
if possible.
Then, the final option is to choose not to identify
the users at the device level.
And Chrome Enterprise supports Managed Guest sessions.
And with Managed Guests, the user
can quickly start a session on the device
and get straight into the browser and their apps.
This is particularly useful in shared use cases
or where users do not have a corporate identity
or, potentially, even are not a member of staff.
Think client kiosks as an example.
While the user is not asked to log onto the Chrome device,
they may need to authenticate into a website
or an application in session.
And with Managed Guest session, the user's information
is wiped when they log out, making the device
safe for the next user.
OK, so let's take a closer look then at Managed Guest sessions.
So as I touched on, Managed Guest sessions
are particularly well-suited to spaces where identity is not
required, such as shared back office
device in retail and client kiosks in banks or information
portals in hotel lobbies.
The device can be security shared between users
as no data is stored on the device,
and it's wiped each time the user logs out.
Managed Guest sessions still allow administrators
to control the user experience, and pages
can be set to load on startup, bookmarks can be pushed,
sites can be blocked, and apps and extensions
can be automatically installed.
The session can also be branded using the Avatar and Wallpaper
settings, and custom terms and conditions
can be presented to the user prior to sign on.
For the remainder of this webinar,
we're going to focus on federation using SAML Single
Sign On.
But before we get into the detail, let's
quickly run through some terminology.
So firstly, federation is using a single identity
for multiple applications.
SSO is short for Single Sign On.
SAML a short for Security Assertion Markup Language
and is an implementation of Single Sign On.
And and Identity Provider, or an IDP,
is your single sign on endpoint.
So there's many vendors in this space.
And then a Service Provider, or an SP,
is the application that you're accessing.
So in this case, G Suite, your Chromebooks--
it could be other SaaS solution, like Salesforce as an example.
And then, your user data store is where your credentials
are stored, so your user's account name, username,
and password.
So now let's take a look at the SSO architecture.
So the diagram on the right of this slide
shows the infrastructure.
Everything on the left of the diagram
is running on premise at the customer site.
The right-hand side of the diagram
is Google Infrastructure.
In this example, we're using Active Directory
as our identity authority.
And Active Directory Federation Services would be our SAML IDP.
And we're also using Google Cloud Directory
Sync to synchronize identities to Google Cloud.
User credentials are managed in Active Directory,
and all updates for joiners, movers, leavers--
they continue to be managed here in Active Directory.
Google Cloud Directory Sync is configured
to synchronize any changes made in AD to Google Cloud Identity.
And this is a one-way sync from Active Directory to Google,
so GCDS never writes anything to Active Directory.
So step one and two are actually the same
if you're planning to use Google Cloud Identity
or if you're implementing SAML Single Sign On.
And at this point, your users have a Google account,
which has been created through the GCDS sync.
And if you were using Google Identity,
you would also need to set a password for the user,
so this can be done in the Google Admin console.
And users will be then prompted to sign in to their Chromebooks
using the standard Google Identity flow.
Once the Google identities exist,
then these same accounts can be used to sign into other Google
services, so things like G Suite and Google Cloud Platform
Services if these have been enabled and configured
by the administrator.
In this particular case, we're looking at SAML SSO.
So we need to configure the IDP in the Google Admin console.
We'll look at the specific steps to do this soon,
but, at a high level, we need to provide
the endpoint for the identity provider, in this case ADFS,
and turn on SSO for Chrome users.
We can also redirect managed Chrome OS devices
to the ADFS login page.
And then, with all of this configured,
when the user wants to authenticate,
they are directed to the ADFS login page
where they will continue to log in.
And we're going to step through that for next.
So again, this slide should look familiar.
The diagram on the right-hand side
shows all of the same components.
But this time, we're going to step through the SAML SSO
authentication flow.
Again, we're assuming Active Directory is the identity
provider, and ADFS is providing the SAML and IDP.
When the customer purchases a new Chrome device,
they enroll it into their management.
And then this ties the device to the customer's domain
and ensures that device policy that
has been configured in the main console
gets applied to the device.
The Chrome device receives the login URL
as part of this device policy, and it's
instructed to redirect users to the ADFS login page
to authenticate.
When the user then tries to log in,
the credentials are checked against Active Directory.
If the credentials are correct, the user
is passed the SAML cookie, which will contain the user's Google
Identity.
And this is checked against Google Service.
And once the user has successfully logged in,
the credentials are stored security on the device.
This allows for a future offline logins.
And the administrator can control how often the user
must log in through the IDP.
Now that we have a high-level understanding
of how SAML SSO works on Chrome Enterprise,
let's take a few minutes to walk through how it's configured
on the Google Admin Console.
The first step is to configure a single sign
on from the Security section.
This enables single sign on for all users
in your domain with the exception of super admins.
And your super admins will continue
to use the standard Google Identity flow.
And this is to ensure that you do not lose access
to your admin console if the IDP is configured incorrectly
or if it were to go down.
Note that, by setting up this, your users
will be redirected to your IDP to log
in to Google services, such as G Suite on every device.
This is not just for Chrome OS.
The next step is to enable single sign on for users
signing into Chrome devices.
This is configured at Device Management Chrome, User
and Browser Settings.
And as this is a user setting, you
need to ensure that you're configuring it on an OU that
contains your users.
So there's two settings that you need
to configure on the screen.
So the first one is single sign on,
and this should be set to Enable SAML-Based Single Sign
On For Chrome Devices.
The second setting is, Single Sign On Online Logon Frequency.
And this controls how often the user
is forced to sign in via your IDP as opposed
to doing an offline sign-in locally on the device.
So the default here is two weeks.
But as an administrator, you can make that more frequent.
Moving onto the Device settings, there
are three policies to consider here.
And as these are device policies,
you need to ensure that you're configuring them
on an OU that contains devices.
Starting from the bottom of this screenshot,
the first policy we need to consider
is Single Sign On Cookie Behavior.
This setting controls if the SAML cookie generated
when the user signs onto the device
is available to other apps and websites inside the session.
If this is enabled, then the user
will be automatically logged in to other services that
use the same IDP.
If it's not enabled, the user will
need to re-enter their credentials the first time
that they visit another service that uses the same IDP.
The setting above the Single Sign On IDP Redirection
controls if enrolled devices should bring users directly
to the IDP login page.
And if this is not configured, the user
will be presented with the standard Google login flow.
And once they've entered their username,
they will then get redirected to the IDP.
So enabling this setting saves the user
from needing to enter their username twice.
And then, the setting at the top of the screenshot, the Sign-in
Screen setting, controls if the user
is presented with the option to quickly log back
into a user profile they previously used on the device.
And with this enabled, the user just clicks
on the username and photo and is prompted
to enter their password.
This is an offline login.
They're not being forced through the IDP at this point.
With this setting disabled, the default flow
is to always hit the IDP for authentication.
So once SAML SSO has been configured to use ADFS,
the login flow will look like this.
The user is presented with a message explaining
that the device is managed.
Once they click on the Next button,
they're redirected to the ADFS login screen.
If the user needs to change their password in session,
they can navigate to the Google Identity Security page.
And by clicking on the Password option,
they'll be redirected to the SAML Password Change page.
Again, this will be presented by their IDP.
There are some watchpoints that should be considered
when you're configuring SAM.
SSO, and firstly, only one SAML IDP
can be configured for the domain.
It's not possible to have different IDPs
for different groups of users.
And as explained earlier, super admins
are not forced through SSO.
So that is something to be aware of.
Then, by default, users are only forced through the IDP login
every two weeks.
And as I've touched on, this can be
adjusted using the single sign on online login frequency
policy.
And also, the sign in screen policy
can be used to control the default login.
Another couple of watchpoints around passwords--
so when the user changes their password, either
because they've been forced to do so due to policy
or because they've perhaps contacted the help desk
and asked for a password reset, The next time
that they want to log in on the Chromebook,
they're going to be asked to enter
their old password in addition to the new password.
The old password is being used to decrypt the Chrome profile
on the device before it's re-encrypted
with the new password.
So that's just one to be aware of.
And then also, if you do have a policy for passwords to expire,
say, every 60 days or 90 days.
The user will not get an alert that their password
is due to expire on Chrome OS.
And then, just to touch on some recent updates
and upcoming improvements to this flow--
in Q3 2019, we added the ability to use
Google's two-step verification and risk-based login challenges
with a third-party IDP.
So this means that you can authenticate your users using
your existing IDP and then prompt them
to use a one-time passcode.
And there's no integration between your existing
IDP and Google.
You just set up both services, and the two-step verification
will be presented to the user once they've
passed your IDP authentication.
And then, throughout 2020, we're working on improvements
to the password change flow and the in-session
alerts when the Active Directory password is due to expire.
Thank you for taking the time to attend the session.
If you have any further questions
that we've not answered, please email
them to chromeonair@google.com.
And please remember that you can register
for upcoming webinars including our session on Admin Console
Overview and Best Practice on July 23
at chromeonair.withgoogle.com.