[MUSIC PLAYING]
MARC JORDAN: Ladies
and gentlemen,
welcome to Google Cloud
Next and welcome to DEV206,
Scaling with Cloud Identity
for Customers and Partners.
My name is Marc Jordan,
I am a product manager
in Google Cloud, and I literally
only think about identity.
I'm joined today by my dear
friends and colleagues, Pierre
and Francois, who I'll invite
to join me on the stage in just
a moment, but I'm going to take
you through a little bit first.
Francois, head of IT
operations, and Pierre,
the chief technology
officer of Mailjet.
So as I said, I'm
going to talk to you
about the way we think of Google
Cloud's Identity Platform.
I'm going to invite Pierre
to talk about Mailjet,
and then Francois to
discuss how they've
implemented Identity Platform
to scale their global business.
Finally, we're round it
out with some questions.
I encourage you all to ask
questions in the session
or catch us afterwards
in the hallway.
I'm happy to dive deeper,
happy to talk more.
So Identity Platform-- going
back to December last year,
we announced Cloud Identity
for Customers and Partners,
or CICP as we endearingly
called it, as a public beta.
And over the last
three months or so,
we've seen phenomenal traction.
We've had thousands
of developers,
literally thousands of
developers come to our platform
and onboard for all sorts
of different use cases.
We've had people build
identity for things.
So they've gone from
credentials on things
out there in the wild to
short-lived tokens that
are issued by our platform,
being able to interact
with Google Cloud Platform to
sort of push up analytics, push
up data, get things
from storage.
We've had people build
MDM-style platforms,
so logging onto Windows
and Macintosh machines,
and using the platform
that we've built
as the source for credentials.
And we've had people build
next-gen intelligence platforms
across Google Cloud Platform
and all of other Google--
a set of Google services.
And we took this feedback.
We reveled in the fact that
these customers are really
getting a lot of value
out of this service
that we're providing.
And we thought to ourselves,
this Cloud Identity
for Customers and Partners,
it can surely do more than
what we're positioning it as.
And so we went back
to the drawing board,
and I've got two big
announcements today.
The first-- the service is
now generally available,
and so I encourage
even more developers
to start to bring their
production critical workloads
to our service and have this
strong foundational platform.
The second thing is we're
rebranding the platform
as well.
And so what was CICP
is now simply known
as Identity Platform.
And with that,
we're bringing all
of the samples, all the
SDKs, all the documentation,
all the things you'd
expect from a platform
so you don't have
to build identity.
You don't have to think
about cryptography.
We have all of that
covered for you.
So what is Identity Platform?
And really, this is about taking
Google's extensive knowledge
and giving it to
you, our developers,
and to our customers
as a service.
So you can take all the
lessons that Google's learned,
all the battle hardening,
all the stress testing
that we've done over decades
hosting consumer services,
and build that
into your services.
So we break it down into
a few different pillars.
First and foremost,
we want to offer you
Google-grade authentication.
So it's based on widely
adopted Google infrastructure.
We have eight services with
over a billion users each,
and you don't get there by
learning a few things about how
to manage identities securely.
And so, as I said, delivering
that to our customers
is our number one priority.
Second, we want to give you
customizable open source
and open standards so you
can build on top of it
and customize it with
your own look and feel.
If you want your logo displayed
all the way through the login
experience, all the way
into your application,
you should absolutely do it.
If you want the color
red from start to finish,
you should absolutely
do that as well.
So you'll never see a Google
logo, Google log-in screens,
or anything like that
when you use this service.
But we do give you things
like sign-in widgets
to enable you to use some
of Google's best practices
to help people onboard,
to stop dropoff,
to help adoption of your
product and your service.
We have a broad support for
authentication protocols,
so OpenID Connect, SAML,
OAuth, those sort of things
we support out of the box.
And we give you client SDKs
across iOS, Android, and web,
so you have to build
authentication.
You don't have to think about
how to interact with our APIs
in order to get tokens to sign
users in and things like that.
And that's great for serverless,
modern-style applications.
But we understand
that, in many cases,
you're probably moving a
service to Google Cloud
Platform or some other platform,
and you need back-end SDKs.
You've got existing servers.
You want to be able
to validate tokens.
You want to be able to do
things in a secure and trusted
environment.
So we give you server SDKs
across all the languages
you might expect--
Python, Go, Java,
the list goes on.
Now, it wouldn't
be a Google product
if we didn't deliver you
advanced user security.
And so with Google, we deliver--
cross-account protection
is one of the ways
that we help to protect
Google accounts.
And we deliver that if
you build your service
on top of Identity Platform.
So what that means is that,
if a Google account, be
an Enterprise account, a
consumer account, whatever
it may be, is signed
into any service sitting
on top of Identity
Platform, the service
gets a notification that
this account is actively
under attack.
Someone's threatening
this account,
and can log the user out,
force them to reauthenticate,
audit the activity in your
logs, so you can take action.
So you can use
Google's intelligence
to help protect all of the
applications you're building
on top of this service.
We're soon to offer
two-factor authentication
to make that even stronger.
And so we really want to
roll that out and make sure
that we, first and foremost,
deliver things that
are important and meet customers
where they are, but start
to do revolutionary things.
And so you can see some
of the interesting things
we're doing there in
some of the sessions
tomorrow around security keys
and other bits and pieces.
And finally, we're built on
Google's secure infrastructure.
You've probably heard it a
whole lot in the last few hours,
at least, and you'll
hear it a lot more
over the next couple of days.
But everything from
the chips in the bottom
of our servers all the
way up to the data centers
and to the APIs that are going
to be exposed to your end users
is using Google's
secure infrastructure.
And we want to deliver
this at planet scale.
We are a global service.
And we hear over and
over from our customers,
like, hey, I don't
want to have to spin up
a database in Asia
East, and I don't have
to spin up a database in EMEA.
I want this delivered
where my users are.
One user might be in one place
at one point and somewhere else
at another point in time.
Don't make me have to figure
out architecture and things
like that.
Offer it through a
global service with CDNs
where the user is with databases
that are local to the user.
No one just buys Identity.
Identity's not sexy.
I want it to integrate with all
the things I'm already using.
So make it work with functions.
Log it into Stackdriver.
Start to use other
services that I'm
familiar with that I'm
already using, and help
paint this end-to-end solution
throughout the entire journey
my user's taking.
And, most importantly,
you're building a service
so that your users can
interact with your business.
If they can't log in, they can't
interact with your business.
So it doesn't matter how
great your features are,
if they can't get through
the front door, that's
a real problem.
And we understand that.
So we're offering
industry leading
SLA's of 99.95% and
Enterprise-grade support.
So if you're using
Google Cloud Platform,
you have one number to call,
and they can support you
with all of the things that
are important in our service.
So it's great for me to wave my
hands around and kind of talk
about it.
Let's show you through it.
So if we want to
flip to the demo.
This is Google Cloud Platform.
If you're not familiar
with it, it's pretty great.
And in here.
I'm going to go to
the marketplace.
And so as I said,
Identity Platform
is generally available today.
And so if I want
to onboard to it,
I can quite simply go
to the Marketplace,
go to Identity Platform,
and simply enable it.
That's it.
So once the service
is onboarded,
once you're enabled
for this service,
there's all sorts of
things you can do with it.
Here's one I prepared earlier.
So we support a range of
different providers, as I said.
So we support open standards,
OpenID Connect, and SAML,
a range of different
social providers,
as well as signing
in with what users
have, emails and
passwords and things,
as well as anonymous,
which I'm just
going to pause on for a second.
Don't ever store information
about a user you don't need to.
You want to help build
a trust in your brand
and help have a user have trust
in what they're getting access
to.
So start light.
As soon as they access
your application,
you might want to sort start
to remember who they are,
start to keep tabs on
what they're doing.
And then over time, as they
maybe they get to a checkout,
maybe they want to put
their credit card number in
or something like that.
At that point, then
you can step them up.
So you can upgrade
that anonymous account
that you previously created
that's been collecting state
on that user, and then turn them
into a paid user, or a named
user, or something like
that in the future.
So this is really,
really critical
to building that trust, to
build that progressive profiling
sort of chain.
And so once users sign
in the first time,
we then obviously have a
representation of the account.
Now, you'll hear from
the Mailjet team, what
was really important
to us was people
have accounts systems today.
We want to interact
with what you have.
We want to integrate
with the services
that you've already got.
So you can migrate users
with their hashed passwords
directly into our
service, or you
can create brand new accounts
with SAML and OpenID Connect.
And there's no need to create.
These will happen just
in time if you so desire.
So let's quickly flip to a demo.
So as I said, this is a
completely white-labeled
service, so I can do
whatever I want with it.
So I might want to choose
to sign in with Google,
sign in with Facebook,
brand this page the way
that I see fit.
I might also want to brand
it completely differently,
support things like
SAML, OpenID Connect,
maybe integrate with my existing
Active Directory environment.
And so I'm going to
sign in here and use
my super secure password.
And we're going to give
you a JSON web token back.
And so, in this JSON
web token, we're
then going to give you custom
claims, information about what
we're storing for that user
so that then you can take that
into a system downstream.
You might want to get
access to something running
inside of Google Cloud,
maybe a different cloud.
Anything that's got our
SDKs in it works just fine.
The one thing
that's critical here
is that we also
directly integrate
with the Anthos announcement
you heard this morning.
So, if you're looking
to modernize your SaaS
applications, it's really about
starting with a strong Identity
foundation.
And so while you're
modernizing, you
can look to move in place to
a modern Identity solution
and kind of go from there.
So that's the end of the demo.
So, as I said, we're
generally available today.
And without further
ado, I'd love
to welcome my two co-presenters
to the stage, Francois
and Pierre, who'll discuss a
little bit more about Mailjet
and its use of
Identity Platform.
PIERRE PUCHOIS: Hello, everyone.
So, first of all, thank
you very much to be here.
It's a pleasure to share
that experience with you.
So, first, we'll talk
about the implementation,
and we'll introduce the
project on the Mailjet side.
I'm sorry for my French accent.
So the agenda for the
presentation-- so first of all,
I'm going to talk about the
whole backbone or architecture.
Then I will talk about why
we talked about the user
management, why it's
important for us,
and especially why we
choose Google for that.
And Francois will talk
about the implementation
and especially the feedbacks
we can give to you today.
And mainly, the bigger
objective is really
to share our
experience with you,
so there is a Q&A
session just after.
So who we are--
we are emailing email
service provider.
We send all over the world more
than 2 billion email comments.
We sent marketing and
production emails.
And there is a huge
probability that you
have an email we sent to
you recently or actually is
doing the response.
The platform is really key for
us regarding the sending speed
rate, which is something
really important,
especially on the
[INAUDIBLE] side.
We also have a big
marketing ecosystem
on top of the platform.
And we have a
complete set of API.
Let's say that all
our architecture
is reachable for the API.
So this is the global picture
of our key architecture.
As you can see, we
have first of all,
[INAUDIBLE] layer so data
center network server SMTP.
On top of that, we have
all the API ecosystem
private and public.
As I said, all our let's
say, core application
reachable for the API.
And we have three
ecosystem on top of these.
The first one is the, let's
say, the marketing ecosystem
with a lot of different features
and applications, [INAUDIBLE]..
All you need to send your
beautiful newsletters.
And so this is the
first ecosystem.
The second one is
the API ecosystem.
So you can reach directly
all our functionalities
directly through the API.
And the third one is the, let's
say, integration ecosystem,
which is really important
for us because we
have a more and
more big partners,
then we have to integrate.
So you can imagine that using
that kind of architecture,
we need a very huge
and strong and studied
user management system.
So what is a CIAM?
Customer Identity and
Access Management.
So you probably already
know about that.
Marc explained that just before.
But as a quick remember, it's
a service to manage users.
Let's say it's user database.
It's also a solution
to authenticate user
on the platform on the solution.
And it's a set of feature to
power the user experience.
So Marc talked about that.
We have a two-step
authentication for example.
A deep log, SSO, et
cetera, et cetera.
So user management is
everything, especially for us.
Why?
Because we provide services
in B to B and B to B to C. So
we have to face multiple
user integrations issues.
Why?
Because each time we have
to integrate a partner,
we have to take care about the
authentication and the identity
management.
And, at this point,
all the project
are completely different.
So we have to develop a
dedicated platform, a dedicated
solution to fit the needs.
So going to [INAUDIBLE] why
it's really important for us
is regarding the security.
The security is really strategic
regarding the user management.
I think it's quite logical, but
we have to take care of this.
And also managing as we
do now, local IAM solution
is really complex and
requires multiple skills,
especially on the dev side.
And now probably you face
exactly the same needs than us.
We have more and more customer
asking for a social log ins.
So something also we want
to provide to our customers.
And it's quite
complicated when we have
to develop that by ourselves.
And last point,
why it's important?
Because the sign up
process has to really
be fast and easy,
otherwise, you could
lose in terms of efficiency.
Some figures we
are being measured.
So more than the 400K users.
And we have a, as you can see,
more than 8K daily sign ins.
So user management is
really critical for us.
So why we decided
to move on the tour,
let's say, revamp the solution.
First, because though as I said,
it's really strategic for us
because we are the SAS platform.
So we are really directly
concerned by this kind
of solution.
As I said also, we have
more and more partners.
And the having a new
partner on our platform
it's really costly because we
have to develop a dedicated
solution.
So it's not quite easy.
And regarding the
time to market,
it's absolutely not good.
So that's why we really
wanted to review complete 3D
solution this architecture.
We also have more
and more customers
asking for an authentication
directly on their directory.
For example, we have
a big luxury brand,
I cannot say the name here,
but it's a French one.
And it starts with a
C. You will understand.
So they really want to
connect directly their users
to our platform without
managing user-owned passwords.
I can understand in terms of
security is good for them.
So that's why we also have to
provide this kind of service.
The last point, but I'm pretty
sure we are all agree on this,
our set of features
is really limited.
It's limited because we have
to develop that internally.
And usually it's
not the first topic
we want to address when we
developed a new project.
So in terms of a
two-factor authentication,
we really want to
provide distribution.
It becomes a stand out
now in the web industry.
We also want to
provide social log ins.
And we will also need activity
logs on the audit capabilities
because we are ISO
27K certified under.
And regarding the audit
we face if we are.
It's something really important.
And we are not
directly concerned now,
but we are thinking about that.
The mobile
reconstitution is also
something we want to
provide to our customers.
So why did we choose Google?
Good question.
It took time.
First of all, just
to decide that we
will able to externalize
that solution,
because it's really
sensitive, it's critical.
So sometimes it's quite
hard to externalize.
So first, we decided to
go for an externalization.
And then we had to
choose the partner.
So why Google?
For many reasons.
So first, because we
are listed on the GCP.
So a [INAUDIBLE].
We go natively.
We looked at the
Google solutions.
Also because there
is a Google provide
a lot of functionalities as
Marc presented just before.
Also, because it's
really easy to integrate.
And you will see it took us less
than six months to integrate
IP for the identity platform--
Sorry.
That's the ICP-- in
the now solution.
And it's so it's scalable,
which is also something
really important for us.
We are growing fast.
So we really need to have a
natively scalable solution.
And also, for the
security, I think
Google is really strong
in terms of security.
[INAUDIBLE] for sure.
So that's why we decided
to go to with Google.
Two cons-- let's talk
about that just one minute.
The vendor dependence--
so you have
to accept that you are
linked with Google.
So it's something you
have to deal with.
And you also have to
accept to externalize
that kind of
solution, and to have
a core service in your
architecture based
on the external PasS solution.
So it depends on your business.
You have to think about that,
having the pros and the cons.
But for our case,
we definitively
decided to go with Google.
And we did the implementation
in a very easy way, I would say.
We can talk about
that a bit later on
if you want to go more into the
details regarding the decision.
Francois.
FRANCOIS FANUEL:
Thank you, Pierre.
So regarding the
implementation--
so as Pierre said, we have
a lot of different use cases
to integrate customers with
a similar user database.
Some want an id connect.
Other want to use
a G Suite account,
and we still have
our own user database
that we manage today with
logins and passwords.
So when you have to do
everything, it's complicated.
It takes time.
Hard to secure.
It's not really flexible.
And if we dig into details,
this is oh, it works today.
The yellow parts are what
we manage there directly.
So yeah, it's a huge
ecosystem to manage.
It's also hard to yeah--
there is not a lot
of value into that.
So it's really hard for
us to dedicate developers
developing identity solutions.
So, in this architecture,
all the connections
with external directories
or with our partners
is something we
wanted to externalize.
So, if we go to the
target architecture--
in the target
architecture the system
is really much more simpler.
We just have to integrate
with identity platform SDKs
all user database
at Google and create
connector between our partners
and the Googles authentication
system.
So we still have to
distribute tokens
for our partner integrations.
We still have to also
have some lookups
if we want to integrate
with enterprise directories.
I will talk about that later.
But still, the system are
really much, much simpler.
You have just one SDK on your
web application to integrate.
And on our side, we
also use the REST API
to directly integrate identity
platform admin features.
So on the client side,
we use the web SDK, which
is super easy to integrate.
And we use the REST API.
So you will see into
the documentation
it talks a lot about the SDKs,
but not a lot about the REST
API.
So there is a REST API.
The features are complete.
So you can use it.
And that's what we choose to do.
On the server side,
for [INAUDIBLE]
you will use the REST API also.
In this project
we choose to first
just do a drop in replacement of
our main authentication system.
So only the user
password system.
And add the other
features after.
This way, we were
able to develop
really fast or this project.
And adding other
features is really simple
because it's already prepared
the identity platform.
In terms of timeline--
so, along this year, like
two months this year,
because of what Pierre said,
really a lot of pros and cons.
So we had to decide wisely.
And then the implementation
was really fast.
Architectural design
in January, development
in February and March.
And as now, the product
is generally available.
We'll be able to launch.
We decided to not launch
within the beta period
because this is all
when the policy is,
but now it's
generally available.
Some implementation
tips-- so when
you do a project
like that, you have
to keep in mind that you have
your own database on our side.
It's something like 400K users
to migrate from one system
to another.
And unfortunately, when we
choose several years ago,
we choose the proprietary
encryption [INAUDIBLE] system
for passwords, which
is not supported
by Google because there are a
lot of [INAUDIBLE] algorithm
available.
But [INAUDIBLE] the other ones.
So we had to find
a way to make what
our users without any
service interruption.
And so resetting
passwords for everybody
was not something we can do.
So what we decided to do is
to do a two-step migration.
First step, during
your long period,
we will collect user passwords
when they log into our system.
So the workflow is like that.
A Mailjet user
authenticates around
our current internal database.
And if the password is
varied, we will generate.
We will sign up the user
to identity platform
with this password.
And when we will have something
like 80% of all database,
migrating like that we'll
be able to switch and say
to the 20% that
didn't [INAUDIBLE]
during the migration
phase, that they'll
have to change their password.
So there are a lot
of ways to do that.
We decided to do that
like that, because we
didn't want it to lose a lot of
users' time when they log in.
In identity platform,
there are quotas.
So the quotas are
well documented.
But you cannot always ask for
a temporary increase if you
generate a lot of users--
of sign ups.
There is in the console
something to do that.
Another thing's that great
in identity platform is logs.
So you have activity logs
for basically everything.
And they are mostly
free for the most part.
Use it a lot.
It's really helpful
to ease the debug.
It's also really helpful
for auditability.
So, as Pierre said, we
are ISO 27K satisfied.
We have to keep a lot of logs
due to this certification.
So it's really helpful.
And it's accessible through--
If you use Google Cloud,
it's really easy to access
like, old user logs.
For REST API, the [INAUDIBLE].
So if I ever comment
on this product,
it was really great to
integrate, great to really fast
to integrate.
Docs are sometimes
a bit hard to find.
So with the revamp
of the name, it
may be interesting to
consolidate everything.
There is a REST API
and the docs are there.
Finally, just to show you we
revamped the authentication
page.
So as you can see, we
have social log ins
on the top of the page.
And we'll probably
change a bit this page
when we will integrate
the federation
with other directories
by removing the password,
the password box.
What we want to do is
provide a seamless experience
around users.
So we'll probably just ask
them to put their email,
and check in their
own database which
federated identity provider
is used by this user
before redirecting him
to the right system.
This way we'll be able
to easily redirect
the user is using
federated identities
or ask them for a password
in a similar phase.
So we probably have a two-step
authentication phase to provide
a seamless experience.
But you can also just put a
button like, in the [INAUDIBLE]
to ask for a federated
identity provider.
Marc.
MARC JORDAN: Thank you so much.
So we just did general
availability today.
And this is really
just the start for us.
Thanks so much for
the Mailjet team
for sort of getting on there
and giving us feedback.
And so we've heard that loud
and clear some of the things
that they've said.
And so we continue to innovate.
And I'm pretty excited to
show them some of the things
we've got coming out
in the near future.
But even beyond that,
we've got so much more
that we want to do.
And so we offer strong
authentication today.
How can we make
authentication so strong
that users are never impacted by
the authentication experience,
but they have the strongest
possible authentication
mechanisms?
So we're really passionate
about protecting end users,
making sure that they have
this beautiful experience end
to end into your application.
They're only prompted
for authentication
when they need to.
And when they do
go through that,
it's through the strongest
mechanisms possible.
More extensibility--
we are a platform.
So how can we deliver
even more extensibility?
Google can be opinionated about
some of the things that we do.
But how can we offer the
right solutions for you?
And you say, well, I really
like this-- sort of these three
building blocks together, but
I need to put these extra two
pieces on top of it.
And we're doing all sorts of
interesting stuff integrating
across Google Cloud with
some of the announcements
you'll hear this week, and some
future announcements to make
sure that you have
the right pieces
to extend sort of
wherever you want to go,
whether it be hybrid
environments, on prem,
more GCP, other services,
and things like that.
So we're investing
really heavily
in our extensibility story.
And finally, more integrations.
As I said, there's great
integrations with things
like Function, Stackdriver.
We're doing a lot of
work at the moment
with other parts of the business
that are really interesting.
And so once you have a user,
knowing the user's identity
is extremely valuable.
And then being able to
sort of track that journey
be able to feed that
into dependent systems,
be able to take action,
be able to understand,
perform analytics,
and things like that.
These integrations
are really important,
not from a security
perspective necessarily,
although they are
valuable, but it's really
about getting the most
value you possibly
can out of having users
access your system,
understanding their behaviors.
And so we think that's
really important.
So it is a price to product.
And pricing kicks in at
general availability.
We do offer a pretty
generous free tier
if you do want to get started
and get playing with it.
And these are list prices.
So if you do have
an account rep,
please tell them
to reach out to me
and happy to have
a conversation.
So as I demonstrated
in the demo,
I encourage you to go try it.
The free tier is
really, really generous.
I'm going to give it a test.
If you are staying on board
to GKE, GKE On Prem, Istio,
all of those bits and pieces,
this is a fantastic service
to help you board
to that quickly
if you want to
Google stack that's
going to work, or start
to take these identities
and use them wherever
you have go to service.
[MUSIC PLAYING]
