►
From YouTube: SAML Knowledge Sharing (Manage 201)
Description
The Manage team at GitLab is giving talks to share knowledge on particular topics. The aim is to make it easier for others to contribute, both within the team and beyond
This presentation introduces SAML at GitLab with a demo and goes into a bit of depth on the protocol, the codebase, local development with GDK and our vision for multi-tenant Group SAML on GitLab.com
Slides are linked to from https://gitlab.com/gl-retrospectives/manage/issues/7, along with details of upcoming 201 sessions.
---------------
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
So
one
of
the
things
we
wanted
to
do
within
the
manage
team
is
to
share
our
knowledge
more
widely,
because
a
lot
of
the
things
we
do
are
really
expertise
or
really
narrow
focuses
which
one
person
shares.
So
myself
have
been
working
on
sam'l
a
lot,
but
M
has
been
working
on
smart
card
authentication.
James
Lopez
is
the
Expo
and
import-export
and
Rubens
the
expert
and
Billy
and
I.
A
On
a
lot
of
these
things,
we
don't
have
much
visibility
into
what
other
members
of
the
team
do
and
even
less
for
people
were
not
not
on
the
team.
So
we
thought
we'd
create
these
201
sessions,
where
we
kind
of
go
into
quite
a
bit
of
depth
about
how
we
work
on
these
these
areas
and
also
that
will
help
other
people
who
want
to
contribute
or
to
review
the
things
we're
working
on.
A
So
today,
I'll
go
over
quite
a
lot
of
things,
but
starting
with
what
what
is
Sam
or
why
it's
important
a
description
of
the
protocol,
how
to
actually
get
started
working
on
this
and
then
I'll
go
on
to
some
other
things
like
the
security
implications
of
some
of
these
things.
So
what
is
sam'l?
It's
a
single
login
solution,
so
I'm
sure
you're
all
familiar
with
things
like
Twitter,
sign-in
or
Google
sign-in,
which
we
use
ourselves
at
get
lab.
A
So
it
means
you
could
just
click
what
click
one
button
and
you're
signed
into
the
service,
but
there's
another
side
to
this,
which
is
for
the
company.
They
get
a
lot
more
control
over
how
our
user
authenticates,
so
they
might
enforce
there
or
one
uses
two-factor
authentication
or
they
might
control
which
services
you
can
access
or
even
remove
access.
When
you
leave
the
company,
so
you
go
to
sign-in
and
it
no
longer
works.
The
company
doesn't
have
to
worry
too
much
about
that
because
they
set
up
their
system
and
there
everything
just
works.
A
So
sam'l
stands
for
security
assertion,
markup
protocol,
sorry
markup
language
be
some
other
ways
and
that
the
key
word
here
is
assertion.
So
this
is
a
confident
and
forceful
statement
of
fact
or
belief.
So
sam'l,
let's
the
organization,
make
a
confident
statement
that
this
this
user
is
James
his
user
ideas,
two
seven,
four
one,
eight
his
email
address
is
jailers
Jones
at
github,
calm
and
then
he's
a
member
at
the
back
end
developers,
group
and
he's
on
the
manage
team.
A
So
we
kind
of
so
that's
what
an
assertion
is
and
that's
kind
of
the
key
to
understanding
this
house.
Emma
works
getting
more
into
the
detail.
It's
an
XML
based
protocol.
So
you
see
here,
we've
got
an
assertion:
it's
got
lots
of
different
sections.
The
kind
of
interesting
ones
are
these
attributes,
so
we've
got
a
new
ID
attribute
to
use
a
one
here.
We've
got
an
attribute
that
maps
to
group
one
and
an
email
attribute.
A
Another
really
key
thing
here
is
the
name
ID,
because
that's
what
we
use
to
link
a
user.
So
what?
When
the
identity
provider,
which
is
the
service
you
put
your
password
in
see,
it
returns
its
response?
It
says
this
is
user
one
or
this
is
user
james
at
example.com,
and
so
that
means
which
user.
This
is
that's
the
name
ID.
A
So
if
you're
kind
of
flavor
of
how
the
protocol
works,
people
normally
would
show
you
this
kind
of
diagram.
So
you've
got
the
user.
You've
got
the
identity
provider
and
you've
got
the
service
provider,
which
is
in
our
case
gitlab,
but
that's
way
too
complicated
to
follow.
So
instead,
I'll
give
you
a
quick
demo,
so
I'm
a
very
high
level.
We
have
this
kind
of
my
semi
button
and
that's
in
this
case
I've
caught
it
myself
and
I'll,
be
the
organization
name
and
so
a
user
who
wants
to
authenticate.
They
click
that
button.
A
A
So
go
into
that
a
bit
more
later,
but
in
this
case
it's
it's
one
I'm
running
locally
on
my
machine,
but
in
other
cases
I'll
be
your
act
ad
FS,
pink
identity,
one
login
and
behind
the
scenes
the
company
will
have
their
own
system
where
they've
got
all
their
users,
and
so
it
will
so
the
user.
It's
just
they
enter
their
password,
but
behind
the
scenes
it
can
be
or.
B
A
Beer
feel
free
to
jump
in
more
questions
in
a
while
cuz.
It
there's
a
lot
to
go
through
a
lot
to
take
in
sorry
yeah,
so
click
sign-in
and
you've
ended
up
on
on
get
lab
and
I'll
I'll
show
you
that
again
and
we're
signed
in
as
user.
One
I'll
show
you
that
again,
but
using
a
tool
to
show
you
what's
actually
going
on
underneath.
A
This
tool
is
called
sam'l
chrome
panel,
but
there's
also
sam'l
tracer
for
Firefox
and
I've
linked
those
later
so
and
this
time,
of
course,
we
already
signed
in
on
the
identity
provider.
So
when
I
click,
this
button
I'll
immediately
be
signed
in
and
redirected
back,
but
there'll
be
a
lot
going
on
underneath
which
these
are
won't
see.
A
A
One
of
the
things
here
is
we've
said
the
issuer,
so
that's
who
we
are
so
they
can
look
up
which
service
we
are
and
respond
appropriately,
and
another
thing
we've
we've
sent
in
this
request
is
where
we
want
the
user
to
be
sent
back
after
this
is
all
over
and
and
that's
because
this
is
a
browser-based
protocol,
so
everything's
happened
in
in
the
browser
in
these
requests.
One
other
thing
to
note
is
that
this
request
actually
looks
like
this,
because
it's
base64
encoded.
A
A
Yep
perfect
question,
because
that
leads
on
to
the
next
part,
so
the
identity
provider
responds
with
its
sam'l
response
and
back
to
that,
that
key
part,
it's
the
security
assertion,
markup
language.
It
replies
with
an
assertion
can't
find
it
in
the
end
of
the
assertion,
but
the
stuff
is
all
in
here.
So
one
of
the
things
is
the
name
ID.
So
in
this
case
it's
a
really
simple
thing.
A
It
said
this
is
user
1
and
it's
also
replied
with
some
other
stuff
that
I
screenshotted
before
so
it
should,
with
the
user
and
with
the
group
one
other
thing
would
that
is
important
for
security
is
that
this
is
a
signed
response,
so
it's
replied
with
a
signature
value
and
also
a
copy
of
its
certificate.
So
we
can
check
that
it's
signed
correctly.
A
Just
to
go
over
some
of
those
concepts
again,
so
you've
got
the
identity
provider,
so
that's
where
you
sign
in
that's
often
called
the
IDP.
So
if
you
see
that
means
the
identity
provider,
the
service
provider
is
Sackett
lab
or
any
other
service
like
office,
you
might
be
signing
into.
You
can
request
the
response.
The
name
ID,
the
issuer,
the
outreach
to
the
response,
school
and
I
just
put
some
of
these
in
here,
but
in
case
anyone
wasn't
watching
the
demo.
A
The
next
thing
is
how
we
linked
accounts,
so
when
a
users
signed
in
and
they
click
that
button,
we
link
their
account
using
that
name
ID.
So
we
say
the
user
currently
signed
in
is
the
same
person
as
name
ID
one,
and
we
remember
that
link
for
future
silence
with
instant
Sam.
All
users
can
also
automatically
be
created,
so
these
are
two
signs
in.
We
can
create
an
account
on
get
lab
for
them,
and
things
are
a
bit
more
complicated
on
github.com
and
so
I'll
describe
that
and
any
questions
so
far
cool.
A
A
So,
instead
of
having
this
kind
of
button
on
the
Left
which
says
my
salmon,
when
you
click
it,
when
you
go
to
users
sign
in
you
have
a
page
for
each
group,
and
so
you
get
something
like
this
on
the
right
saying
sign
in
to
my
org
and
so
that
the
configuration
page
currently
looks
something
like
this.
And
so
they
so
instead
of
having
an
config,
it's
configured
per
group
and
that's
an
important
difference,
because
we
then
need
to
look
up
which
group
someone's
signing
in
for
and
then
respond
appropriately.
A
But
this
group
sam'l
github.com,
it's
like
we've
been
working
on
this
year
and
it's
it's
very
different
and
one
of
the
things
is
the
trust
model,
because
that
that
identity
provider
that
someone
configures
could
actually
be
a
malicious
one
and
one
we
don't
trust
so
come
back
to
that,
a
bit
later
and
yeah
so
I'm
gonna
have
a
sip
of
water
and
all
things
have
any
questions.
Good.
A
So
how
do
you
get
started
with
all
of
this?
Six
months
ago?
I
just
said:
you
need
to
set
up
Active
Directory,
you
need
to
configure
ad
FS.
You
need
to
configure
some
users
on
that,
you
need
to
add
certificates
and
they
need
to
set
up
some
LDAP
transformers,
but
you
don't
have
to
do
any
of
that,
because
we
have
docker
container
in
GDK
and
so
I'll
run
you
through
how
to
configure
it
with
that.
A
A
That
we're
configuring
the
two
things
same
as
before,
where
we
want
to
be
sent
back
so
that
sometimes
called
the
assertion
consumer
service
URL,
which
is
a
mouthful,
sometimes
called
the
callback
URL.
Am
I
configuring
the
issuer,
which
here
is
called
the
entity
ID?
So
there
can
be
a
lot
of
confusion.
Confusing
terminology,
like
sometimes
assertions,
are
called
claims,
but
it
all
starts
to
blend
in
and
make
sense
eventually
and
next
we'll
go
in
and
we'll
configure.
A
A
A
Now
one
of
the
differences
I
mentioned
with
group
sam'l
is
users,
don't
sign
in
from
the
kind
of
global
get
lab
comm
page
they
sign
in
on
a
on
a
different
page
for
each
group.
So
we
go
to
this
one
and
we've
got
a
warning
saying
you're
about
to
link
this
account
and
they
will
grant
you
access,
and
so
it
can
sign
you
in
to
get
lab.
So
these
will
click
authorize
and
be
redirected
to
simple
sam'l
and
she's,
using
one
again.
A
A
A
A
A
A
C
A
A
D
C
A
So
the
allowing
this
on
github.com
with
signing
is
a
work
in
progress,
might
request,
so
I'll
just
describe
how
it
is
at
the
moment.
But
if,
if
when
you
visit
that
page,
you
don't
have
an
account,
it
will
redirect
you
to
the
identity
provider
because
it
doesn't
know
if
you
have
an
account
yet
now.
Redirects
back
will
show
the
registration
page
and
if
well
the
sign-in
or
registration
page.
A
If
someone
signs
in
then
it
will
redirect
them
back
and
they'll,
be
their
account,
won't
be
linked
for
the
first
time
and
if
they
register,
when
they
do
that,
it
will
be
linked.
So
we
we
don't
have
a
automatic
registration
process,
but
because
of
the
way
we're
doing
the
redirects
they'll
get
shown
the
sign
in
or
sign
or
register
the
page
if
they
haven't
linked
an
account
before.
A
So
now
I'm
gonna
go
through
just
some
areas
of
the
code
so
that,
if
you're
reviewing
a
merge
request
or
trying
to
look
for
security
flaws,
you
have
a
vague
idea
of
where
to
look
for
things
that
there's
quite
a
lot
to
go
through.
So
I'm,
just
gonna
start
jumping
into
the
code
and
kind
of
showing
you
different
areas
so
feel
free
to
jump.
In
with
any
questions.
A
A
Sorry,
this
externally
ID,
which
is
the
name
ID,
and
so
with
that
combination
of
we
know
who
it
is
from
the
name
ID
and
we
know
which
identity
provider
saying
that
saying
who
that
is,
we
can
identify
the
user
to
look
up
the
sam'l
provider
itself
is
just
those
things
we
configured
in
the
in
the
user
interface.
So
that's
the
certificate
fingerprint
with
the
link
to
the
group
and
through
those
identities.
A
A
So
one
of
the
the
key
things
about
how
this
works
within
our
code
base
is
that
we
use
Omni
off,
and
so
that
comes
in
before
we
kind
of
hit
the
rail
stack.
We
Omni
off,
does
it
stuff
in
in
recommittal
where
and
it
has
its
own
kind
of
way
of
doing
things,
so
it
has
a
setup
phase
and
a
request
phase.
So
that's
where
we
create
that
author
request
we
saw
earlier
and
then
it
has
a
callback
phase.
A
A
A
So
with
C,
it
just
uses
the
plain
library
itself
and
just
to
give
you
a
like
when
I'm
developing
this
a
lot
of
the
time.
I
do
have
to
come
in
to
the
actual
library
and
have
a
look
at
what's
happening
here
and
that's
all
configured
here.
So
we've
got
the
request.
Phase
he's
just
figured
settings,
it
does
a
bunch
of
stuff
with
the
fingerprint
and
it
also
calls
through
to
Ruby
sam'l,
which
is
a
library
that
does
to
kind
of
load
lower-level.
A
A
And
we
kind
of
have
asserts
we
kind
of
have
two
different
paths
that
can
be
taken
here
ones
when
the
users
already
signed
in
and
ones
when
they're
not
signed
in,
and
so
it's
it's
a
bit
weird,
because
we
do
two
different
things
and
everything's
in
two
different
places.
But
the
kind
of
key
thing
to
wrap
your
head
around
is
that
we
have
an
identity
linker
and
in
here
we
say
if
the
users
signed
in
then
we
either
link
that
link
their
account.
A
A
If
the
user
is
not
signed
in
then
there's
this
whole
other
bit
of
code,
but
it
also
handles
things
like
logging.
All
the
events
setting
remember
me,
tokens
dealing
with
two-factor
authentication
and
we're
having
that
shared
with
the
other
waste
users
can
login.
It
means
we
don't
end
up
accidentally
forgetting
to
do
two-factor,
authentication
with
sam'l
or
anything
like
that.
A
A
The
main
kind
of
ways
that
Samwell
helps
protect
us
is
it's
got
this
this
protocol,
that's
very
well
thought
out
very
well
specified,
and
then
it's
signed
with
with
that
certificate,
and
so
you've
got
xml
signing
and
you
call
these
validations.
The
different
parts
of
that
xml
are
correct
and
as
we
expect
that,
but
that
also
means
that
those
are
all
the
places
where
it
can
go
wrong.
So
attackers
can
bypass
the
xml
siding.
Sometimes
they'll
do
this
by
creating
a
second
element.
A
And
so
that
is
there's
all
sorts
of
very
clever
attacks
based
around
this,
so
yeah,
oh
I've
got
a
slide
here,
showing
all
the
different
validations
that
Ruby
symbol
does
I
see.
So
you
can
see
it
invalidates
the
response
state.
It
validates
the
signature,
validate
that
the
issuer
is
the
correct
thing,
because
if
it
was
in
get
lab
but
office
they'd
send
that
sam'l
request,
then
it
would
be
completely
invalid.
Invalid
invalidates
the
time
on
the
response.
A
So
when
we
get
back
a
response,
it
only
has
a
short
window
in
which
it's
valid
and
that
prevents
replay
attacks.
But
then
it
has
another
time
that
says
this
user
is
definitely
this
user
for
this
many
years
or
months
or
weeks,
and
so
they
can
so.
The
identity
provider
can
make
these
assertions
with
different
time
periods
as
well
yeah.
A
Every
single
one
of
these
is
something
that
an
attacker
can
work
around.
So
we
have
to
be
careful
thinking
about
those.
Luckily,
Ruby
someone
takes
a
little
of
that
away
and
does
it
all
for
us,
but
there's
a
lot
of
things.
We
also
need
to
be
care,
careful
of
and
I'll
jump
to
this
slide
for
a
bit.
One
of
the
complications
with
this
multi-tenant
sam'l
is
that
the
identity
provider
might
not
be
trustworthy.
A
So
when
we're
configuring
in
the
config,
our
own
identity
provider,
we
know
it's
trustworthy,
but
when
we
allow
any
user
on
github.com
to
ride
their
own
identity
provider,
they
could
then
trick
users
into
visiting
some
some
site
where
randomly
on
the
internet
being
redirected,
their
malicious
identity
provider,
which
could
then
send
back
a
valid
response
all
by
itself
and
then
hey
they
can
sort
they
can
that
identity
provider
can
now
assign
its
own
users
into
get
lab.
So
they
can
then
go
on
their
computer.
A
Pretend
to
be
you
and
hijack
your
account
so
that
there's
you
so,
although
we
haven't
changed
much
with,
we
have
to
be
extra
careful
and
we
also
need
to
protect
against
social
engineering,
because
we've
got
that
that
warning
page
saying
you
sure
you
want
to
link
this
account.
But
if
someone
doesn't
know
what
that
means,
they
might
give
mission
to
someone
else
to
sign
them
in,
and
some
of
those
attacks
have
been
talking
about.
A
Dev
allowed,
uncontrolled
access
to
office
365
and
to
github,
so
they're,
not
just
theoretical
attacks,
they're
ones,
that
people
have
actually
got
out
and
found
ways
to
for
research
purposes
and
act
but
yeah.
So
what
we
need
to
make
sure
we're
very
thorough
when
reviewing
this
and
think
about
all
these
different
possible
scenarios.
D
A
So
it's
something
we
could
place
an
organizational
process
around
this
and
saying
whenever
someone
enable
sam'l,
we'll
check
their
identity
provider,
but
another
kind
of
adapter,
maybe
kind
of
not
like
that
as
much
is
that
some
might
set
up
a
certain
identity
provider
just
to
play
around
with
things
and
then
that
might
have
a
vulnerability
that
can
then
be
if
someone
can
get
access
to
N
and
one
of
these
valid
organizations,
they
can
start
attacking
uses
as
well.
So
it
still
wouldn't
completely
protect
us
and
it
would
add
a
lot
of
process
overhead.
A
B
A
It's
something
we'll
plan
to
do,
but
at
the
moment
they
configured
the
identity
provider
for
the
top-level
group
and
we
don't
do
any
anything
other
than
adding
the
users
to
the
group.
But
because
we've
got
those
assertions-
and
they
can
say
this-
this
users
in
group
X
we've
got
plans
so
then
use
that
and
say
then,
for
certain
doing,
group
X.
A
B
Okay,
so
the
user
flow
right
now,
so
let's
say
this
gets
deployed
to
get
lab
comm.
You
know
next
week
or
whatnot
people
set
up
their,
they
have
a
group,
I
get
lab
group,
they
set
up
their
own
sam'l
provider
right
and
what
does
that
give
them
now
that
gives
them
ability
to
just
people
to
log
in
and
get
access
to
that
group,
or
with
that
start
I
manually,
add
users
group,
so.
A
What
we
already
get
calm
is
is
that
ability
that,
when
someone
signs
in
with
sam'l,
it
automatically
adds
them
to
the
group.
So
if
I
sign
in
to
that,
my
org
sam'l
provider,
I
also
Matthew
get
added
to
that
top
level
group.
What
we
don't
have
on
github.com
yet
is
the
bit
that
she
signs
you
in
to
get
lab
comm.
They
need
to
enter.
They
use
name
password
first,
so
it's
it's
kind
of
halfway.
There
got.
B
A
That
kind
of
leads
us
onto
that.
The
things
that
we
want
to
do
next,
that
there
are
also
things
that
we're
gonna
need
security
review
on
things
that
we're
gonna
direct
review
on
and
things
that
I'd
like
to
be
able
to
sign
to
maintain
as
well
I
mean
saying:
I,
don't
know
what
this
is
I'm,
not
too
sure.
A
There's
also,
this
metadata
configuration
because
one
of
the
things
that
sam'l
administrators
like
to
do
is
just
get
a
a
URL
for
some
XML
author
configures
everything
for
them,
and
the
next
stage
is
providing
administrators
with
more
power
over
enforcement
because
they
want
to
be
able
to
say
all
the
users
on
this
group
or
use
sam'l
so
that
no
one
could
be
added
or
accidentally
get
added.
That's
just
a
normal
gait
lab
comm
user.
A
Another
thing
that
we
see
people
wanting
is
the
ability
to
say
that
that
user
is
currently
signed
in
with
sam'l
they
haven't
signed
in
with
their
github.com,
username
and
password,
and
so
that
lets
them
fraud.
It
reasons
say:
yes,
they've
definitely
used
all
our
policies,
they've
used,
two-factor
authentication
and
we
haven't
removed
them
from
our
system,
because
they're
signing
in
with
the
right
provide
with
sam'l
and
then
two
other
things
are
making
those
memberships
expire.
A
If
someone
doesn't
hasn't
signed
in
recently
and
then
allowing
them
to
mass,
add
users
and
remove
users
when
they
leave
the
company
and
to
do
that,
we
can't
really
use
sam'l
because
it's
a
browser-based
protocol.
So
if
someone's
left
the
company,
they
can't
exactly
login
and
go
through
the
flow,
and
we
trusted
to
do
that.
So
we
need
to
look
at
another
tip,
SCO,
M
and
then
kind
of
net
next
area
for
improvement.
A
So
recap:
sam'l
great
for
organizations
managing
users
great
for
individuals
only
having
to
click.
One
thing
to
sign
in
group:
sam'l
is
the
thing
I've
been
working
on
and
we've
got
a
lot
more
to
go,
but
it's
it's
gonna
be
very
powerful
for
organizations
which
want
to
move
to
get
lab
comm.
Instead
of
self
hosting,
is
there
something
that
for
sales
is
really
important
and
something
that's
really
really
important
for
a
lot
of
organizations?
A
A
They're
kind
of
a
different
beast
in
some
ways,
so
forget
up
calm.
One
of
the
reasons
not
to
look
at
LDAP
is
it
sends
passwords
over
the
internet,
so
someone
using
LDAP
date.
They
put
their
password
in
for
the
DUI
and
we
don't
really
want
organizations
giving
having
their
users
give
us
their
password
each
time
and
sending
that
over
the
Internet
to
their
server.
And
it's
a
very
different
approach
for.
A
Self
hosted
things
when
there
is
all
within
a
contained
network.
Sometimes
it's
just
the
convenience
for
the
users.
It's
it's
one,
click
if
they
already
signed
in
to
their
office,
account
or
the
juror
account
or
anything
else.
It's
just
one
click,
and
they
don't
even
need
to
notes.
They
don't
need
to
put
in
a
password
each
time
yeah.