►
From YouTube: GitLab Access Manager (Project FastPass) - v1.11.4 Demo
Description
GitLab Access Manager (GLAM) is the next generation of IAM and RBAC access request automation being built by GitLab IT Engineering. This is a weekly demo for the v1.11.4 iteration (CalVer).
https://about.gitlab.com/handbook/business-technology/engineering/#access-manager-engineering
DRI: Jeff Martin, Dillon Wheeler, Peter Kaldis
00:00 - First Marker
01:00 - Auth Namespaces Schema
07:26 - Saas Namespaces Schema
17:58 - Code Demo
25:26 - Database Demo
29:00 - Reference Links
A
A
A
A
Well,
the
first
step
that
we
can
use
is
what's
called
an
auth
provider
field
and
we'll
look
at
the
details
of
that
in
a
few
minutes.
But
essentially
that
says
if
the
job
title
of
this
user
is
seniority
systems
engineer.
I
can
then
map
that
from
my
octa
profile
over
into
my
gitlab
access
manager,
user
profile,
the
same
thing
applies
with
groups,
and
this
looks
for
a
certain
attributes
and
so,
for
example,
a
department
attribute
and
we'll
map
it
and
say
if
I
belong
under
information
technology.
A
I
would
like
to
automatically
map
you
to
that
group.
That
group
may
have
downstream
impacts
to
what
roles
you
could
access
to
what
applications
you
can
request,
access
to
and
all
sorts
of
approval
and
action
flows
that
follow
that
now.
Auth
groups
are
a
much
more
powerful
thing
than
they
might
seem
it's
more
than
just.
You
belong
to
a
member
of
a
group
they're
used
as
part
of
a
role-based
access
control
mechanisms,
and
so
the
groups
impact
with
the
roles
with
the
users,
and
then
we
also
have
the
idea
of
service
accounts.
A
We're
not
going
to
spend
any
time
looking
at
that
today,
but
that
simply
allows
our
other
systems
to
integrate
with
glam
for
bringing
data
in
and
out
right,
okay.
So,
let's
dive
under
the
hood
of
what
this
schema
actually
looks
like
so
from
the
provider
perspective
we
mentioned
a
moment
ago.
We're
going
to
dive
into
the
fields
what
it
essentially
looks
like
is
at
the
provider
level.
What
key
is
it
providing?
So
I
mentioned
a
job
title.
The
job
title
will
map
to
the
title
inside
of
our
database
right
and
then
over
on
the
groups.
A
It's
looking
at
a
couple
different
things,
so
the
first
it's
going
to
ask
which
provider
is
it?
We
know
that
already,
which
group
are
we
going
to
provide
access
to
and
then
what
type
is
it?
And
this
is
going
to
be
one
of
two
options
right
now.
The
first
is
a
default,
so
every
user,
who
has
this
value,
is
going
to
be
mapped
or
with
a
meta
key
and
what
the
metakey
is
looking
at.
Is
that
attribute
right
and
then,
if
it's
a
certain
value,
then
map
to
this
group?
A
The
other
thing
that
we
have
as
well
as
part
of
our
new
audit
system
is
the
ability
to
have
an
approval
flow
tied
to
it,
and
this
simply
says
in
order
for
this
group
to
get
automatic
access
or
these
users
automatic
access
to
this
group.
This
is
the
approval
flow
that
everyone
in
the
approval
chain
is
signed
off
on,
so
we
can
audit
trail
back
all
of
our
automatic
mappings
without
the
need
for
manual
access
requests,
there's
a
lot
more
power
under
the
hood
with
that
we're
not
going
to
spend
any
further
time
today.
A
Looking
at
that,
though,
as
you
drill
down
from
the
auth
provider,
we
have
our
auth
users
table.
I
mentioned
a
moment
ago
that
job
title,
that's
where
that's
coming
in
here,
we
have
other
data
that
looks
very
reminiscent
of
if
you
had
a
local
user
authentication
system.
Ours
is
very,
is
very
similar
in
that
right.
We
don't
need
to
have
all
these
fields.
However,
it
gives
us
a
lot
more
control
in
terms
of
what
we
can
access,
how
we
can
manage
different
two-factor
authentication.
A
Although
we
use
octa
for
sign-in,
there
may
be
other
aspects
that
we
want
to
put
more
security
controls
in
place,
since
this
does
give
a
little
bit
of
a
keys
to
the
kingdom
type
of
system.
So
we
have
all
the
security
options
in
place.
We
can
choose
to
turn
them
on
and
we'll
figure
that
out
as
we
go
through
the
implementation
now
looking
at
groups.
This
simply
shows
how
we
map
users
to
groups.
So
we
saw
a
moment
ago
how
users
can
automatically
be
mapped
based
on
the
metadata
they
have
from
octa.
A
The
other
way
we
can
do
it
is
by
manually
requesting
access
inside
of
the
github
access
manager
ui.
When
that
happens,
that
same
approval
flow
is
going
to
apply.
Now
it
may
be
one
where,
if
you're
a
member
of
a
certain
group,
you
get
access
a
little
bit
easier
than
other
members
might
more
of
exception
security.
You
know
overrides
and
approvals
and
such,
but
this
is
where
it
maps
to
it.
One
of
the
new
benefits
that
we're
going
to
be
introducing
is
the
expiration
and
audits.
A
What
that
basically
says
is
that
you're
going
to
get
access
for
a
period
of
time
and
your
approval
flow
has
an
audit
after
number
of
days
built
into
it.
So,
for
example,
you
may
get
access
for
180
or
365
days
before
the
security
team
or
your
manager
or
another
person
in
the
company
is
going
to
look
at
that
data
or
we
can
set
an
expiration
date.
This
is
going
to
be
very
helpful.
We
need
to
do
short-lived
credentials
so,
for
example,
you're
helping
respond
on
some
incident.
A
So
we
get
a
lot
more
control
of
the
automation
on
the
provisioning
and
deprovisioning
without
handing
human
intervention
on
a
system
administrator
side,
that's
one
of
the
big
power
benefits
of
what
glam
can
do.
So
that's
how
users
and
groups
work.
If
we
take
a
step
back
and
look
at
how
providers
fit
in
and
how
the
groups
fit
in,
we
mentioned
service
accounts.
You
can
see
those
here
if
you're
interested
all
the
auth
roles
that
we
see
here
are
basically
the
different
abilities
for
you
to
access
areas
of
github
access
manager.
A
A
Now
each
techstack
application
is
going
to
be
a
little
bit
different
right
in
what
they
call
things,
what
we're
trying
to
give
access
to
and
a
big
part
of
what
we
have
to
do
a
lot
of
our
design
challenge
in
this,
and
this
is
where
the
glam
design
is
a
little
trickier
and
a
little
more
ambiguous
in
at
first
glance,
but
there's
a
lot
more
power
under
the
hood.
So,
let's
take,
for
example,
one
password
one
password
has
vaults,
it
has
groups,
it
has
users,
but
not
every
text
stack
application
has
vaults.
A
So
why
would
we
create
a
database
table
called
sas
provider
vaults?
It
wouldn't
make
any
sense.
It's
only
used
for
that
one
application
and
we
have
170
plus.
So
what
we
end
up
doing
is
introduce
the
idea
of
an
entity
and
the
entity
is
kind
of
a
universal
term
for
is
it
a
vault?
Is
it
a
group?
Is
it
a
license?
Is
it
whatever?
It
is
think
of
how
your
applications,
if
you're
a
system
owner
are
set
up
today?
A
What
are
you
granting
access
to
if
we
look
at
it,
maybe
more
broadly
or
maybe
something
universal,
that
everyone
would
understand
today?
What
about
get
lab
groups
or
gitlab
projects?
Maybe
there's
a
gitlab
project
that
you
need
access
to,
that
has
restricted
membership
to
it.
That
allows
us
the
ability
to
say
the
entity
would
be
the
gitlab
project,
or
maybe
it's
a
gitlab
group
over
top
of
it.
A
We
would
then
grant
access
to
a
certain
group
of
users
or
a
specific
user
through
the
sas
instance
group
or
sas
instance,
users,
and
that
gives
us
the
different
overlays
and
controls
while
maintaining
a
very
simple
database
structure
and
allowing
a
lot
more
of
a
almost
a
polymorphic
database
relationship.
If
you
will
to
allow
us
to
control
that-
and
that
brings
us
more
in
the
benefits
of
in
the
google
workspace-
we
can
do
google
drives,
but
we
don't
have
to
do
any
changes
to
our
database
architecture.
A
A
So
the
groups-
this
isn't
the
groups
that
we
think
about
the
mglam,
it's
the
groups
that
they
actually
have
in
their
system,
so
we
may
have
auth
groups
on
our
site.
We
mapped
our
users
to
the
groups
themselves
are
what
would
actually
be
showing
up.
So
a
really
good
example
of
this
may
be
google
groups
in
google.
We
have
a
group,
we
have
members,
we
would
actually
create
a
group
in
google
and
it
would
show
up
as
a
sas
instance
group.
A
It
may
also
show
up
as
a
sas
instance
entity
from
an
approval
perspective,
but
don't
worry
about
the
details
of
that
we'll
take
care
of
that.
The
sas
instance
users
then
get
mapped
into
that
group,
and
that
group
has
rights.
So
when
you
think
about
gcp,
when
we
map
access
to
a
gcp
project
for
a
large
group
of
users,
we'll
use
groups
instead
of
mapping
each
user
individually.
A
This
is
how
you
would
get
access
to
that
group
and
then
grant
the
group
access
to
that
entity
and
the
entity
would
be
the
gcp
project.
Those
are
some
of
the
complexities.
We
don't
want
to
spend
too
much
time
more
going
into
them
today,
but
just
gives
you
some
of
the
design
thinking
that
goes
into.
Why
we're
doing
what
we're
doing
here.
A
So
one
of
the
things
that
we're
going
to
run
into
is,
we
have
a
lot
of
variances.
We
have
a
lot
of
different
system
administrators
across
the
company.
A
lot
of
different
owners
and
departments
are
doing
different
things.
We
may
call
something
different,
so
we
have
a
sas
provider
and
that
is
essentially
the
company
that
provides
the
service.
A
A
There's
one
instance:
every
sas
provider
is
going
to
have
a
default
instance,
but
what
if
you
have
more
so
in
aws,
the
sas
provider
would
be
amazon
web
services,
but
the
sas
instance
would
be
each
of
the
aws
accounts
that
we're
then
granting
access
to
that
have
their
own
identity
and
access
management
elements
to
them
that
are
isolated
from
each
other.
So
this
gives
us
a
scalability
model
right
now
at
a
business
metadata
level.
A
What
if
we
want
to
bucket
and
categorize
things
in
different
ways,
so
in
a
normal
parent-child
relationship,
a
category
a
provider
can
only
have
one
category
well
what
if
the
I.t
team
wants
to
categorize
things
differently?
What
if
the
security
compliance
team
wants
to
categorize
things
differently?
A
What
if
the
different
business
owners
think
about
it
differently,
and
so
this
gives
us
the
ability
to
use
multiple
categories
for
each
provider
and
have
a
lot
more
of
a
many-to-many
relationship
going
on.
We
don't
worry
about
the
details,
only
that
we're
building
a
lot
of
the
flexibility,
because
naming
things
is
hard
and
not
everyone's
going
to
agree
on
that.
A
This
gives
us
the
flexibility
of
everything,
has
a
unified
identifier,
and
all
the
database
is
already
built
to
support
that
where
we
can
put
aliases
and
names
and
allow
people
to
organize
things
in
a
way:
that's
more
human
friendly
without
having
to
have
challenges
with
different
system,
iterations
and
variances.
That
can
really
cause
problems
down
the
road.
A
A
In
many
respects,
this
could
be
things
where
some
of
the
actual
provisioning
notes
go
in
different
things
and
elements
that
get
put
in
there
by
the
system
owners.
Various
things
can
get
added
there.
It
just
gives
us
the
flexibility
for
storing
it.
Everything
else
that
you
see
here
is
simply
mapping
that
information
across
and,
as
you
go
over
to
sas
instance,
users,
every
system
treats
a
user
a
little
bit
differently.
Some
have
a
shared
sso
account
for
their
service,
and
it
gets
then
invited
as
a
member
into
different
organizations.
A
This
table
here
allows
us
to
track
all
those
variances
in
one
place
and
we'll
simply
use
the
fields
that
apply
depending
on
what
the
sas
instance
or
sas
provider
is,
so
those
are
different
flexibilities
that
we
have
the
only
thing
I
want
to
draw
your
attention
to
for
today
to
keep
an
eye
out
for
future.
Demos
is
the
expires,
app
provisioned
at
an
unprovisioned
ad,
and
this
is
allowing
us
to
track
that
life
cycle
of
the
user.
So
glam
is
a
lot
more
than
just
getting
you
access,
it's
tracking.
A
How
long
do
you
have
access
when
it's
time
to
off
board
or
if
you're,
going
to
change
roles,
we
automate
the
entire
workflow
of
removing
your
user
account
or
removing
your
resources
or
unmapping
your
permissions?
If
you
move
to
a
different
role
that
has
different
permission
sets,
so
we
have
a
lot
of
flexibility,
so
the
database
schema
design.
We're
doing
today
is
laying
a
very
strong
foundational
groundwork
for
everything.
We're
doing
in
the
future,
make
sense
cool.
A
So,
there's
a
lot
of
roles
and
users
that
map
into
here
we're
not
going
to
worry
too
much
about
this
other
than
saying
that
the
roles
are
what
each
of
the
sas
providers
call
them
we're
not
defining
anything
special
here.
Many
in
many
cases
a
person
is
simply
a
member
or
user
manager.
Maybe
an
owner
there's
usually
about
five
roles
that
most
sas
providers
have
we're
simply
adding
those
into
our
database.
So
we
know
how
the
role
mapping
works
and
having
a
local
cache
to
be
able
to
do
all
the
relationships.
A
You
can
see
a
lot
of
the
lines
and
interdependencies
here
now,
if
there's
more
complex
scenarios,
amazon
web
services
is
one
that
comes
to
mind,
because
that's
what
I
deal
with
a
lot
is,
there
are
hundreds,
if
not
thousands,
of
roles
in
there
same
thing
for
gcp
and
some
others
that
are
just
a
little
more
complicated
salesforce.com
could
be
another
one
that
allows
us
a
lot
of
flexibility
to
add
in
and
then
map
it.
So
we're
not
having
to
do
a
lot
of
different
work
in
different
providers.
A
We
bring
a
lot
of
the
like
work
into
our
site
and
we
know
what
to
choose
from
a
drop-down
menu
and
we
create
that
unified
user
experience
and
similar
to
how
gitlab
is
the
single
devops
platform.
This
is
the
single
access
management
platform,
we're
bringing
all
the
pieces
together.
So
we
do
all
the
talking
and
all
you
have
to
do
is
go
to
a
single
ui
and
get
access.
So
that's
what
we're
looking
at
those
are
the
different
pieces
and
then
at
the
sas
and
instance,
entity
level.
A
We
mentioned
this
earlier,
we're
not
going
to
dwell
on
it
too
much
further.
Only
that
there's
going
to
be
different,
variances
that
we're
going
to
discover,
as
we
start
working
with
the
different
you
know,
different
sas
providers
and
what
we're
trying
to
integrate,
but
for
every
all
the
text,
tech,
apps
that
we've
looked
at
so
far.
This
model
should
work
pretty
well
for
us.
So
there's
that
that's
how
that
works,
and
then
we
can
also
do
a
lot
of
the
group
mappings
again
we're
not
going
to
spend
a
lot
of
time
on
it.
A
Just
simply
know
that
we
can
map
into
each
entity
what
group
it
has
and
so
going
back
to
our
earlier
one
password
example:
we
can
map
a
group
of
engineers
into
a
something
or
maybe
you're,
trying
to
use
teleport
to
do
ssh,
access
and
you're
an
engineer
into
our
systems.
You
need
to
be
a
member
of
a
certain
group
in
order
to
use
teleport
and
so
there's
different
elements
that
get
into
this,
and
this
is
where
this
all
gets
mapped
at
right,
so
taking
a
step
back.
What
we're
looking
at
here
is
our
sas
providers.
A
Each
task
provider
can
multiple
sas
instances
and,
if
you're
still
confused
about
what
a
sas
instance
is
think
about
the
url.
So
what
url
are
you
signing
into
and
so
we're
simply?
If
you
have
there's
multiple
urls,
maybe
there's
a
production
and
a
staging
you'd
have
two
instances
and
we're
granting
access
to
production
and
staging,
as
instance,
a
or
instance
b.
If
you
will
right
and
then
obviously
all
of
our
instance
groups,
users,
roles
and
the
entities
that
we
saw
down
below.
A
A
Here's
the
relationships
in
which
I'm
going
to
you
know
connect
to
the
other
models
and
then
we're
going
to
look
at
how
that
data
schema
looks
we
actually
bring
data
into
it
and
look
at
our
sql
database
to
the
what
we're
going
to
see
later.
You
know
in
future,
demos
is
how
we
use
that
data,
but
for
data.
Let's
just
look
at
how
data
looks
inside
of
these
schemas
right
all
right.
So,
let's
bounce
over
here
and
look
at
the
migrations,
and
so
in
our
application.
A
Here
we
have
our
app
gitlab
access
manager,
app
and
down
here
we
have
database
migrations
and
if
we
look
at
auth
provider
groups,
this
is
one
we
mentioned
earlier
about
how
a
user
is
going
to
get
access
to
a
group
depending
on
the
value
they
have
from
their
octa
metadata,
and
so
we
saw
the
schema
and
some
of
the
different
pieces
and
the
slides.
This
is
what
it
looks
like
in
the
code
and
all
that
we're
simply
doing
is
specifying
what
we're
going
to
create
a
new
database
table
called
auth
provider
groups.
Okay,
easy
enough.
A
We're
then
going
to
give
it
all
the
different
types
of
fields,
any
constraints
and
all
the
different
values
that
we
might
need
to
have
right.
All
of
our
foreign
keys
in
our
database
use
the
uuids
right
so
no
problem
there
and
then
we'll
simply
do
the
type
remember
right
before
I
mention
default
meta.
So
in
this
case,
most
of
the
things
we're
going
to
do
are
meta
great
fantastic.
A
As
we
create
different
keys,
it's
going
to
look
and
say,
create
a
group
and
then
specify
the
key.
That's
looking
in
this
case.
It
might
be
geo
underscore
department,
the
meta
value
might
be
information
technology,
it
might
be
engineering
development,
it
could
be
engineering
support
could
be,
sales
could
be
customer
success.
Any
of
the
different
departments
will
have
different
groups
corresponding
to
them
right.
So
that's
pretty
easy.
That's
the
way
that
that
works.
A
When
we
map
that
provider
group
over
to
a
model,
this
is
a
little
more
of
the
behind
the
scenes
magic
as
a
user.
You'll,
never
see
this,
you
don't
care
about
this.
This
is
just
showing
the
engineering
and
the
process
that
we
go
through
in
order
to
make
this
all
possible
is
there's
a
model
for
auth
provider
group,
and
we
simply
tell
it
what
database
table
are
we
looking
at
great?
A
We
then
have
the
ability
to
control
all
our
validation
rules.
This
is
where
it's
checking
to
see
if
the
inputs
are
provided
by
the
user,
either
in
a
web
form,
if
someone's
trying
to
do
some,
you
know
csrf
or
any
of
the
other
aspects
or
api
requests.
All
that
goes
through
these
required
filters
right
and
it
just
double
checks
and
make
sure
that
everything
is
good.
So
we
have
store
rules
and
we
have
update
rules.
A
A
Now,
that's
for
getting
the
data
into
the
database
right,
that's
what
the
model's
defining.
We
can
also
define
how
it
comes
out,
and
this
is
where
typecasting
comes
in
and
we
simply
say
what
are
the
different
fields.
What
format
are
they
going
to
come
out
at
for
the
vast
majority
of
this
you're?
Never
going
to
see
or
care
about
this?
A
The
important
part
here
is
when
we
deal
with
api
responses,
that's
where
we
want
to
make
sure
we're
giving
you
the
right
format
and
also,
if
we're
dealing
with
any
sort
of
date,
time
conversion
stuff.
Sometimes
it
could
pass
in
a
string.
Sometimes
it's
passed
as
a
date.
Time
object.
There's
different
elements
that
get
into
there
right
dates.
We
can
do
it.
You
know
conversions
on
that,
but
the
model
has
a
lot
more
importance,
in
my
opinion,
with
relationships
and
there's
different
types
of
relationships.
A
There's
parent
relationships,
there's
child
relationships,
many
to
many
distant
child
relationships,
and
this
is
saying
what
is
telling
the
model.
What
other
database
tables
can
I
go
talk
to
and
what
are
the
columns?
What's
the
foreign
key
id
that
I'm
going
to
go,
look
for,
and
so
in
this
particular
case
for
an
auth
provider
group
there's
a
couple
different
parent
relationships.
A
A
When
I
go
to
the
auth
providers
table,
I
can
use
the
key
that
I
have
in
my
table
to
go
and
search
that
table
for
the
id
same
thing
goes
for
off
group,
and
so
the
auth
group
itself
is
saying:
go
find
the
auth
group
for
this
id
and
match
it.
So
this
is
simply
giving
the
system
the
way
to
map
what
database
value
and
row
am
I
looking
for
when
I
go
to
the
other
table.
A
That's
what
parent
relationships
are
all
about
child
relationships,
kind
of
do
the
inverse
it's
looking
at
a
table
and
saying
I
want
to
find
all
records
that
belong
to
me
and
then
use
this.
I
this
id
my
id
to
look
it
up,
and
so
in
this
example,
is
we
can
find
hey
here's
an
auth
provider
group.
I
want
to
find
all
the
team
members
that
have
signed
in
from
the
information
technology
team
and
I
want
to
find
all
those
users
that
have
been
automatically
mapped.
A
I
will
then
look
at
that
database
value
and
bring
that
in
right.
So
that's
what
it
allows
us
to
do.
So,
that's
the
you
know
parent
relationships,
child
relationships.
A
lot
of
this
is
kind
of
fundamental
to
object-oriented
programming
and
some
of
the
things
that
it
doesn't
matter
what
language
you
use
or
what
framework
you
use.
The
fundamentals
are
all
the
same.
A
This
kind
of
gives
you
a
little
bit
of
an
intro
to
how
we
do
database
work
right
and
how
we
try
to
connect
the
dots.
So
that's
what
that's
all
about
right
and
there's
different
many-to-many
relationships,
the
deeper
that
we
get
into
our
different
models.
The
more
that
you're
going
to
see
a
lot
more
of
that
we're
not
going
to
spend
a
lot
of
time
going
into
that
today.
A
Right,
there's
also
the
users
table,
I'm
not
going
to
spend
a
lot
of
time
demoing
through
this
specifically,
but
it
simply
gives
you
a
little
more
of
the
complex
nature
of
the
different
fields.
We
have
how
we
can
work
through
it
and
at
the
model
level,
there's
more
things
that
we
manipulate
right,
because
the
user
is
the
core
of
what
we're
trying
to
do
right.
It's
what
we're
trying
to
grant
access
to
it's.
A
What
we're
trying
to
give
approvals
for
so
there's
a
lot
of
different
elements
that
we
have
and
we
can
control
through
this,
and
so
it
kind
of
gives
you
an
overview,
a
taste
right
of
what
we
can
and
what
we
can't
do,
and
so
that's
kind
of
how
we
set
this
up
right.
So
there's
where
we
look
at
from
here's,
how
migrations
work,
here's,
how
models
work?
There's
a
lot
more
coming.
A
You
can
see
the
roadmap
for
the
other
pieces
that
build
on
top
of
it
with
services,
to
manipulate
that
data
api
to
consume,
that
data
web
uis
to
see
dashboards,
look
at
lists
create
forms
all
those
pieces
are
coming,
but
these
are
the
building
blocks
that
we
use
to
get
there.
So
this
is
just
demos
focus
on
here's,
the
building
blocks
of
this
week
and
what
we've
been
building.
A
So
let's
do
one
final
thing
and
let's
look
in
our
database
ourselves,
so
I've
just
done
an
import
of
some
of
the
values
that
are
in
here.
We
don't
have
the
full
manipulation
ability
yet,
but
we're
able
to
fork
off
of
some
other
code
that
we've
written
in
the
past
to
bring
some
data
in
to
show
you
how
this
works
and
so
for
auth
provider
groups.
A
You
can
see
here
that
we've
got
a
couple
different
groups
going
on
it
doesn't
matter
what
the
group
id
is
for
the
mint
for
the
moment
right.
The
meta
key
itself
we're
looking
for
octa
to
look
at
the
gl
division.
If
the
value
is
engineering,
then
map
that
user
to
this
group
right
simple
enough
if
the
value
is
gl
department
here,
another
key
is
gel
department.
The
value's
customer
support
map
it
to
that
group
and
it
will
simply
loop
through
all
the
groups
and
see
which
ones
you
match.
A
It's
that
simple
maps
you
to
it
right
and
where
that
helps.
That
is
when
you
end
up
over
in
auth
users,
you
can
see
if
we
go
ahead
and
we
look
at
just
my
profile
over
the
right
hand,
side
if
you
look
at
the
red
json,
the
provider
metadata.
This
is
what
octa
knows
about
me,
and
so
this
is
where
it's
grabbing.
Hey
my
department
is
business
technology.
A
We
are
introducing
one
additional
layer,
deeper,
called
department
groups
which
we're
inheriting
from
our
infrastructure
standards,
and
what
that
allows
us
to
do
is
go
level
below
it
and
say
business
technology
as
a
department,
and
then
it
engineering
is
the
sub
department
or
department
group.
If
you
will
right,
and
so
those
different
elements
allow
us
to
map
a
lot
of
pieces,
one
other
trick
that
we
do
have
as
well
is.
A
We
are
going
to
use
auth
provider
groups
for
managers,
so
for
those
where
we
don't
have
enough
information
schema
behind
the
scenes
of
what
groups
we
have
at
gitlab,
which
it's
a
challenge.
We
have
right
now
we're
iterating
we're
getting
better,
but
we
can
actually
use
the
manager
name
or
the
manager
email
address
or
the
manager
id
to
do
a
lookup
and
say
if
your
manager
is
peter
in
my
case,
then
map
automatically
to
it
engineering.
A
If
your
manager
is
someone
else
in
the
engineering
development
organization,
then
automatically
map
to
the
manage
access
import
group.
All
these
different
kinds
of
things
are
ways
that
we
can
do
that.
So
there's
a
lot
of
power
under
the
hood
here
we
built
a
lot
of
universal
dynamic
abilities
to
do
this.
A
So
that's
where
we're
going
right,
we're
bringing
a
lot
of
the
data
schemas
to
this
that
we
haven't
had
before
and
we're
not
worrying
as
much
about
static
yml
files
and
merge
requests
and
some
of
the
get
mentality
we're
trying
to
build
the
right
tool
for
the
job
and
the
biggest
thing
that
we're
facing
today
is
we're
getting
asked.
Well,
aren't
there
better
sso
and
iem
solutions
out
there?
A
A
A
So
our
goal
ultimately
is
to
build
the
right
platform
for
gitlab
and
all
the
universal
elements
of
the
things
we
have
to
deal
with
at
gitlab.
So
there
you
go,
that's
what
we're
doing
with
our
database
schema.
So
far,
additional
things
are
coming
with
the
action
and
the
approval
flows
that'll
be
following
up
in
a
future
demo,
but
for
today
that's
what
we've
got
to
share
with
you.
A
So
thank
you
so
much
for
that
and
with
that,
if
you'd,
like
any
additional
reference
links,
do
you
want
to
browse
this
code
or
have
a
look
at
some
of
the
more
of
the
explanation
of
the
documentation
around?
It
feel
free
to
check
out
these
links
and
with
that,
thank
you
so
much
and
have
a
great
rest
of
your
day.