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]