MARC JORDAN: Welcome to the
Google Cloud Security showcase,
a special web series where we'll
focus on security use cases
that customers can
solve with Google Cloud.
My name is Marc, and
I'm a product manager
at Google Cloud.
Today, we'll be walking through
one of the top questions we
get from customers.
How can I add authentication
and identity management
to my own apps?
Let's see how this looks
in Google Cloud Platform.
The first thing we have to do
is enable Identity Platform.
Now, you can see I've
got this pinned here,
but it normally hides
down below in the tool
section of the left navigation.
But I can also go to
the Cloud Marketplace
in order to enable
Identity Platform.
So let's go through
that flow now.
In the marketplace, if I search
for identity and platform,
you'll be able to select
the product and enable it,
if it's not enabled
in your project.
Now, Identify Platform is a
customer identity and access
management product,
and really helps
you to secure, and have your
applications be more secure,
and take Google's best
practices with you
when you develop your
applications and services.
So let's enable the product.
And I've actually
already enabled
Identity Platform inside
of this GCP project,
and you can see
the first thing I'm
greeted with is a number
of different providers.
Now, we support a range
of social providers, be it
GitHub, or Facebook,
or LinkedIn,
or Microsoft, as well
as being able to sign in
with an email and password.
And interestingly enough,
SAML and OpenID Connect--
the enterprise
federation standards
that the organizations you're
working with often use.
An interesting one to talk
about briefly is anonymous.
Anonymous enables you to start
to get to know your users.
Start to develop a relationship
with them before you even
ask them for any information.
So you can slowly gain
more and more information
about the user, and
when the time is right,
ask them to enter a
username and password
or ask them to link
a social credential.
We think this is really
important to develop trust
with end users that are
coming to your applications
or services you
might be building.
If I come into
email and password,
I can actually do some
extra configuration.
So we support things
like passwordless login.
We know that end
users hate having
to enter usernames and
passwords when they come
to a new service, and so
with passwordless log in,
it doesn't get any more
simple than them entering
an email address, and
suddenly they get a link
that allows them to sign in.
Now, inside of my
project, I've already
got some users already created.
But you can add users
directly from the console
or with our set of admin
SDKs or client SDKs as well.
And in the settings
menu, we have a range
of different configurations.
We understand that account
linking gets quite challenging,
where a user brings a
username and password,
and later wants to add a
Facebook credential or a Google
credential or something
else to the user account
so they can have a range
of ways to sign in.
So linking accounts cuts
out all the complexity.
If we see two users
that look the same
and have the same
credentials, we're
able to link them together
to provide the end
user with options.
With activity logging,
we're able to send
all of the information about
administrative activities
and user sign in
activities and everything
else into Stackdriver, so you
can start to develop trending,
and understand how your
users are using your product,
as well as how administrators
are making changes
to certain pieces of
functionality that
might be critical to the
functioning of your business
or to your application.
And finally, we have a range of
different self-service options.
So we could allow users
to create their accounts
automatically, or
force an administrator
to go through the
process of creating them,
and the same with delete.
So let me show you
briefly how this looks.
I'm going to come to
this application here,
and so I've built the front
end on Google App Engine,
and I have a range of
different sign in methods.
So I can sign on with
email, sign in with Google,
GitHub, as well as that
anonymous authentication.
We also support the enterprise
federation standards
that I spoke about earlier.
So if you want to
sign in with SAML,
if your business partners
already have their own IDP,
they can simply click a
button and get redirected
to their existing
identity providers,
whether it be SAML, OpenID
Connect, or something else.
Now, configuring this
front end was really,
really quite simple.
If I flick back for a moment to
the Identity Platform interface
and go back to the
providers, you'll see here,
there's application
setup details.
If I click that, I have
all the configuration
I need to be able
to add Identity
Platform to the project or to
the service that I'm building.
So what does that look like?
If I come into Cloud Shell, you
can see this is my index page,
and all I've done is simply
add the configuration
into my application front end
and simply initializing it.
What that does is
then initialize
the front end and
initializes the widget
so they can add those
sign in providers.
And adding sign
in providers is as
easy as specifying the
providers that you want to add,
and so this is the code that's
running on my Google App Engine
front end.
So let's go back
to our application,
and what I'm going
to do here is I'm
going to sign in with email.
I pre-created an account here,
and I'm going to sign in.
Now, what's happened here
is it's minted a standards
based OpenID connect ID token.
It says some information
about me, maybe my name,
and how I've signed in.
In this case, I signed
in with a password.
It also gives any other
information about me
that might be relevant.
In this case, I
specified an email,
and we can see that I haven't
yet verified my email address.
We support a range of different
custom claims and custom
attributes that you can
also add to this ID token
so that you can build
authorization rules inside
of your application
or service, based
on the parameters
of a user, or based
on the attributes
associated with them.
So signing in is one
piece of the puzzle,
but it actually gets interesting
when you start to use it.
So while I built my front
end on Google App Engine,
I built my back end
on Google's Anthos.
So here, I'm going
to use my token.
And the first thing I
want to do is try and hit
Anthos back end, my Anthos
APIs, without authentication.
And what we can see
here is that I get
this 401 unauthorized error.
So I haven't sent a
token to the back end,
and so it's telling
me I'm unauthorized.
And with Anthos, I can do
this without changing any code
on my application or service.
Simply writing a rule, configure
it on the back end service,
and then allowing end
users to try and hit it,
depending on whether they're
authenticated or not.
If I hit this With
Authentication button, what's
going to happen
is I send that ID
token that we saw just a moment
ago to the Anthos back end.
And what I've got is
some rules that say,
hey, this has to be issued
from the Identity Platform
product and the
Identity Platform
service you've configured.
And so in this case, I'm
using some traffic management
against my Hello World
back end in order
to pass that ID token
to the Anthos back end,
and allowing me to get access
to and from the service.
So we have all of this
documented publicly on Identity
Platform public
documentations in Cloud Docs,
and I encourage
you to go and check
that out to learn
more about this
and also configure this
code lab for yourself.
Thank you for tuning in.
Please visit
cloud.google.com/security
for more content from
Google Cloud experts.
[MUSIC PLAYING]
