►
From YouTube: Pinniped Community Meeting - April 15, 2021
Description
Pinniped Community Meeting - April 15, 2021
We meet every 1st and 3rd Thursday at 9am PT / 12pm ET.
This week's discussion centered around LDAP Support and Device Code Flow (current project roadmap items). Shoutout to community member, Scott Rosenberg, for sharing his knowledge and expertise with the maintainers as they work on these issues. Full notes and meeting details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ
A
A
If
you
have
anything
you
would
like
to
put
in
the
agenda
while
attending
this
meeting
or
any
future
meetings,
please
do
so
down
here
at
the
bottom,
at
the
discussion
topics
or
if
there's
anything
else
like
a
question,
you
would
like
to
add
to
the
discussion.
Q
a
here
on
the
github
that
link
is
also
listed
out
here,
looks
like
we
don't
have
any
announcements
for
the
day
so
we'll
just
kick
it
right
on
over
to
status,
update
updates
within
the
project
roadmap
that
is
listed
also
on
the
github
repo.
A
B
Sure
so
ldap
support
is
coming
along
pretty
smoothly.
I
think
it
might
be
best
actually
to
refer
to
maybe
ryan,
to
give
a
status
update
on
where
we're
at
there.
C
Sure
yeah,
like
you,
said
it,
I
feel
like
it's
coming
along
smoothly,
making
a
little
bit
of
progress
every
day,
the
there's
a
pr
open
for
it,
where
you
can
go
and
see
the
commits
that
have
been
made
so
far
and
the
the
eye
just
went
green
last
night
on
the
pr,
including
an
integration
test
that
does
the
whole
authorized
request,
including
the
user's
credentials
with
the
upstream
deciding
what
their
downstream
username
should
be
and
their
downstream
uid
should
be.
B
I
think
we
intend
to
include
before
we
deliver
the
next
release,
which
are
yeah
exactly
these
ones,
group
support
and
then
as
well
support
for
most
common
connection
options,
and
I
think
we
we
actually
have
a
little
bit
of
discussion
that
might
be
useful
to
get
into
today
or
sometime
about
trying
to
validate
what
we
think
the
most
common
options
are
like
what
which
options
give
us
support
for
80
percent
of
the
environments
that
we
think
customers
are
using?
What
gets
us
to
90
percent?
What
gets
us?
B
I
don't
think
we're
ever
going
to
get
100,
because
ldap
is
too
weird
and
arcane
and
there's
so
many
weird
ldap
setups
out
there,
but
trying
to
try
to
get
the
most
bang
for
the
buck
and
also
ship
something
that
is
generally
useful
to
most
people
from
the
first
version.
B
So
I
think
we
can
talk
about
that
in
this
meeting
or
we
could.
We
could
talk
about
it
later.
The
other,
so
the
other
epic,
that
we
have
the
the
on
the
roadmap
for
the
next
release
is
device
code
flow
support.
I
feel
like
we
were
very
unlikely
to
ship
this
in
april.
B
Oh
another,
another
thing
about
the
the
roadmap:
here
we
may
ship
a
080
release
that
includes
some
other
smaller
fixes
and
then
bump
each
of
these
numbers
forward
by
one.
What
to
see,
I
think
we
have
some
changes
that
are
merged
already
for
caching
there's,
a
bug
fix
for
the
bug
fix
I'm
working
on
for
clusters
that
are
suspended
and
resumed
those
those
don't
work
right
now
very
well.
B
We
might
take
those
fixes
and
go
ahead
and
release
that
kind
of
released
with
those
fixes
and
then
shift
ldap.
In
the
next
phrase.
I
don't
know,
I
think
it
kind
of
depends
whether
we
think
so.
Certainly
it
could
be
valuable
to
have
these
bug
fixes
if
you're
using
ocefno
today,
if
ldap
is
ready
around
the
same
time
that
we're
ready
to
ship
this
other
stuff
which
might
be
you
know
the
towards
the
end
of
the
month.
B
I
don't
think
there's
any
harm
in
merging
them
together,
because
there's
not
the
ldap
code,
if
you're
not
using
it
shouldn't,
have
a
big
stability
impact
or
anything
like
that.
Like
there's,
there's
no
reason
you
wouldn't
want
ldap
support,
okay
device
code
flow
support.
I
think,
if
you
click
through,
there
is
a
something
of
a
stub
issue.
B
Device
authorization
grant
is
basically
a
login
flow,
it'll,
be
the
lug
and
flow
between
the
cli
and
the
supervisor,
and
currently
that
flow
requires
the
cli
to
open
a
local
host
listening
port
and
then
the
browser
opens
up
and
at
the
end
of
the
browser
flow
you
redirect
it
back
to
that
localhost
port
and
that's
how
the
cli
then
is
able
to
read
your
tokens
for
your
session
and
that's
totally
functional
and
works
just
fine
for
most
people.
B
But
if
you
happen
to
be
like
an
enterprise
windows
user
and
you
have
some
security,
local
firewall,
that's
going
to
freak
out.
If
you
open
a
listening
port,
you
might
just
not
be
able
to
use
pen
event
today
so
device
code
flow
support
is
one
standard
way
of
doing
a
login
from
something
like
a
cli
that
doesn't
require
that
localhost
port.
So
that's
the
that's
the
reason.
B
The
reason
we
want
to
build
it
is
to
help
support
these
sort
of
this
subset
of
users
that
are
unable
to
use
the
current
login
flow,
and
we
haven't
had
a
lot
of
vocal
requests
from
those
users
yet
so
I
think
we
might
be
waiting
for
validation.
B
This
is
a
little
bit
if
we
were
kind
of
speculating
that
this
is
gonna
be
a
problem.
If
it
turns
out
to
not
be
a
problem,
then
we
probably
won't
build
device
code
flow
support,
because
it's
not
inherently
better
or
more
useful.
B
E
Yeah
so
matt-
and
I
will
be
meeting
up
later
today
to
discuss
road
map
items
device
could
flow.
Certainly
it's
probably
going
to
slip
more
likely,
I
think
is.
We
will
be
doing
some
work
around
the
docks,
which
is
also
represented
in
the
roadmap.
E
And
then
there
are
also
probably
some
other
stories
that
will
make
their
way
in
that
are
around
again
extending
cluster
type
support,
but
this
will
be
updated,
probably
by
end
of
day
today,
taking
into
account
that
we
have
knocked
out
most
of
the
impersonation
proxy
work
already.
There
are
a
couple
of
one-off
stories
that
we
might
prioritize
in
the
backlog
as
well
around
that,
but
we
hope
that
this
will
be
updated
soon.
B
Yeah
we
actually,
we
have.
We
have
a
lot
of
relatively
small
stories
in
the
backlog
that
are
like
we've
been
invalidated
there
in
the
icebox
as
well.
Probably
I
went
through
and
validated
a
bunch
of
stuff
earlier
this
week
and
realized
that
yeah
we
actually
still
have
a
whole
bunch
of
good
ideas
for
things
to
do
to
things
to
improve
about
our
current
code.
B
B
Well,
I
think
that's
really
it
for
the
roadmap
update.
We
don't
have
any
discussion
topics
unless
somebody
if
nobody
has
one
I'm
going
to
propose
that
we
talk
about
adapt
connection
options.
B
I
can
kick
things
off
yeah.
Let
me
find
the
link
that
we.
B
B
B
B
Yeah,
so
I
think
some
of
the
options
we
talked
about
supporting
so
we're
gonna
have
custom
ca
support.
So
so
let
me
talk
about
the
thing
we're
supporting
right
now
and
ryan.
You
can
keep
me
honest,
we're
supporting
just
plain
tls
with
a
custom,
ca
bundle
and
probably,
if
you
don't
specify
the
ca
bundle,
you
get.
The
system
bundle,
that's
yeah.
Okay,
plain
tls
in
in
this
context
means
a
tls
connection
which
inside
of
it
carries
ldap.
I
think,
and
that's
one
common
ldap
configuration.
C
B
Yes,
so
it's
the
same
configuration
as
https
or
ftps,
where
you
take
the
existing
protocol
and
wrap
it
up.
There's
at
least
one
other
connection
option
that
I
know
is
pretty
common,
which
is
start
tls.
B
B
You
can
turn
on
tls
opportunistically
on
the
same
port
and
it
uses
a
little
little
packet.
So
basically,
the
client
connects
plain
text
over
like
plain
text
ldap
and
then
says
hey
by
the
way.
I
see
you're
an
ldap
server,
I'm
an
ldap
client
and
I
want
to
speak
tls,
and
then
they
decide
to
upgrade
that
connection
to
tls
sort
of
in-band
and
it
can
either
be
opportunistic
or
in
either
the
server
or
the
client
side.
You
can
say
that's.
B
The
only
thing
you
can
do
is
upgrade
to
tls
and
if
you
don't
upgrade
to
tls,
then
I'll
close
the
connection
and
anyway
supporting
this
should
be
really
trivial,
because
it's
just
like
we're
using
a
library
that
we
just
need
to
turn
on
a
flag.
I
think
ryan.
Does.
That
seem
to
be
true.
C
That
would
have
been
true
because
the
library
supports
it,
but
the
library
dialer
does
not
support
using
a
go
laying
context.
C
B
Okay,
so
we'll
have
to
actually
send
the
start:
dls
packet,
ourself
and
and
stuff-
I
guess
that's
not
so
bad.
We
might
might
be
able
to
contribute
that
context.
Support
back
to
the
upstream
library
too.
I
don't
know
how
there's
there's
a
lot
of
these
really
fundamental
libraries
like
ldap
one
comes
to
mind,
but
also
the
oidc
library.
We
use
some
of
the
jot
jot
libraries
we
use
that
are
very
popular
in
the
go
ecosystem,
but
are
basically
like
somebody's
side
project.
That's
not
really
very
maintained,
I
feel
like.
F
F
B
Okay,
so
some
other
options
that
I
think
we'd
considered.
Building,
I'm
not
sure
where
we
landed,
one
is
automatic
detection
of
start
tls.
So
I
feel
like
this
is
still
a
good
idea.
So
it's
saying
like
not
only
are
we
gonna
support,
star
tls
and
regular
tls,
but
we're
never
going
to
even
ask
the
user
to
tell
us
which
one
to
use
we're
always
just
going
to
whenever
you
set
up
an
ldap
server,
we'll
go
ahead
and
try
both
see
which
one
works
and
use
that
one,
because
they're
equally
secure.
B
It's
just
a
compatibility
thing.
That
might
be
that's
additional,
like
logic
for
us
to
write,
but.
C
I
I
realized-
I
was
thinking
about
that,
while
I
was
writing
the
tls
code
for
the
client
and
realize
that
that
might
be
a
little
tricky,
because
the
the
way
that
we're
letting
you
configure
it
right
now
is
you
give
us
the
host
name
of
your
ldap
server
and
optionally.
Give
us
the
port
that
you
want
to
connect
to,
but
you
can't
give
us
two
ports.
You'd
have
to
give
us
two
ports.
B
And
we'll
figure
out
whether
that
port
is
start
tls
or
regular,
tls
right
yeah
like
it,
there
tends
to
be
conventional
ports
for
regular
ldap
and
or
it's
like
like
389,
I
think
or
like
that
and
then
start
tl
tls
ldap
is
like
489
or
something
like
that.
But
you
could
run
ldap
on
whatever
port
you
wanted
and
we
don't.
B
I
think
we
could
we
could.
We
could
still
have
a
default
port
of
389
or
maybe
we
could,
if
you
don't
specify
a
port.
Maybe
we
can
try
the
two
common
ports.
I
don't
I
don't
know.
I
feel
the
feeling
would
be
like,
even
if
you
just
give
us
one
endpoint,
but
one
tcp
you're,
basically
telling
us
the
tcp
endpoint,
we'll
figure
out
which
flavor
of
ldap
that
tcp
endpoint
speaks.
G
C
Yeah
yeah,
because
the
start
tls
way
of
connecting
to
ldap
you
do
have
to
connect
to
the
insecure
port
and
then
call
start
tls
like
send
the
start.
Tls
protocol
request
over
the
insecure
so
like
if
we
wanted
to
auto
detect-
and
you
only
gave
us
one
port
number-
we
wouldn't
really
know
which
one
to
try
first,
should
we
try
regular
tls?
Should
we
try
start
tls,
although
I
guess
matt's
right,
we
could
just
try
one.
If
we
get
a
tls
error,
try
the
other
one.
C
B
Thing,
I
could
think.
Oh
sorry,
I
didn't
mean
to
interrupt.
The
only
thing
I
think
is
this
might
be
noisy
in
people's
surfer
logs,
if,
especially
especially,
depending
on
how
often
we
do
this
probing
like,
if
we
do
only
once
when
you
create
the
ldap
identity
provider,
crd
and
maybe
every
hour
or
something
like
that.
Maybe
it'd
be
okay,
but
if
we're
doing
like
this,
every
three
minutes
like
which
is
what
how
we
often
we
resync
right
now
and
we're
probing
and
every
time
we
probe
on
pretty
much
any
server
you're
going
to
get.
B
One
of
them
is
going
to
make
some
kind
of
error
log
on
the
server
side,
saying
like
a
client
connected
and
got
a
tls
error
or
a
client
connected,
and
you
know,
sent
a
bogus
ldap
packet
because
it
was
actually
a
tcp
handshake
at
a
tls
handshake.
B
G
B
G
Isn't
one
of
the
core
requirements
is
that
you
never
talk
to
your
ldap
admin
in
any
of
these
things,
you
don't
ask
them
to
change
anything
about
any
configuration
anywhere
other
than
maybe
give
you
an
ldap
service
account
which
there's
probably
a
form
in
your
it
catalog
for
request
service
account.
That's
a
good
idea,
good!
That's
a
good
goal.
B
So
I
guess
I
don't
know
I
feel
like,
even
even
with
that
concern
about
the
the
noisy
logs,
I
would
still
lean
towards
trying
to
do
this
auto
detection
mode,
just
because
it
lets
us
have
fewer
configuration
knobs
in
the
api,
and
we
can
always
add
them
later,
but
we
can
start
with
a
default
that
probably
it
might
just
be
the
permanent
solution.
It
might
just
be
good
enough
for
everyone
indefinitely.
G
E
Yeah
you're
not
wrong
how
we
go
about
making
this
less
painful
is
obviously
a
running
question,
but
you're
right.
That
was
like
a
big
part
of
the
feedback
we
got.
Was
identity,
sucks.
C
D
So
I
can
say
I
know
four
relatively
large
enterprises
that
use
start
tls
and
do
not
use
ldap
s
currently
that
are
using
uaa,
for
I
mean
with
authenticating
with
ldap
currently,
so
I
have
seen
it,
but
it's
definitely
not.
That
prevalent
from
my
experience
at
least.
B
B
B
If
I
know
that
my
ldap
server
is
ldap
mycompany.l.mycompany.com
and
I
just
try
a
default
ldap
port,
we
should
try
to
maximize
the
chance
that
that
will
just
work
because
I
think
most
in
most
companies.
It
should
be
as
simple
as
I
kind
of
like
know
my
ldap
server
name,
because
I
ask
somebody
and
or
copied
out
of
some
other
systems
config
all
right.
So
I
sort
of
know
vaguely
that
I
have
an
ldap
server.
B
We
can
probably
take
it
from
there
and
detect
a
lot
of
things.
I
think
they
can
the
connection
options
here.
It
gets
more
complicated
when
you're
talking
about
the
the
user
and
group
attributes
and
structure
and
how
to
do
the
searches
and
stuff.
I
think
that
auto
detecting
those
will
be
much
bigger
challenge.
I
think
we
have
that
slated
for
like
a
future
future
milestone,
but
this
feels
like
something
we
can
do.
Are
there
any
other
connection
options?
I
mean
there's
the
tls
versions.
That
might
be
something
you
have
to
configure
like.
B
It
basically,
usually,
I
think
it
would
just
be
implemented
by
the
same
exact
client
code
or
same
exact
server
code.
So,
like
you
use,
start
tls
and
then,
when
you
realize
the
connection
is
now
to
be
upgraded,
you
pass
that
socket
off
to
like
open
ssl
and
you
still
have
a
full,
regular,
tls
handshake.
That
happens
then.
B
B
1.3
there's
a
line
somewhere
because
I
think
we've
already
we've
already
decided
like.
We
really
don't
want
to
support
plain
text
ldap,
because
that's
just
a
pretty
ballet,
it's
a
pretty
bad
idea.
We
really
shouldn't
at
least
at
least,
if
we're
going
to
ever
support
it.
We
need
to
support
it
with
lots
of
loud.
B
You
know
flags
in
the
ui
or
something
that
say
like
this
is
really
insecure.
Are
you
sure
you
want
to
do
this?
I
hope
this
is
a
demo
environment.
Please
don't
turn
this
on.
I
think
we
even
talked
about.
Maybe
this
is
a
slightly
side
topic,
but
if
we
do
have
a
server
like
a
supervisor,
that's
configured
in
like
an
insecure
way
on
on
on
on
purpose
to
actually
surface
that
back
to
the
cli.
B
B
It
to
the
user
so
that
you
don't
forget
basically.
G
C
G
B
I
think
I
think
we
can.
We
can
see
a
potential
future
where
the
penniped
config
looks
like
the
dex
config
or
it
looks,
and
I
don't
mean
to
pick
on
decks
but
looks
like
the
dex
config
or
the
uaa
config.
That's
like
got,
you
know,
hundreds
of
options,
maybe
hundreds
is
an
exaggeration
but
lots
of
options,
and
it's
true
that
maybe
the
defaults
just
work
for
you.
But
if
you
actually
are
sitting
there
trying
to
audit
your
config
and
say,
is
my
config,
correct
and
secure.
B
I
think
that's
the
cost
of
adding
the
options
is
like
it's
not
that
it's
that
much
code
for
us
to
support
wiring
it
through
it's,
not
that
even
like
you
know,
a
more
basic
user
couldn't
just
deploy
it
with
the
default.
It
still
like
reduces
the
it
increases
the
overhead
of
like
maintaining
configs
for
for
environments.
B
If
I
go
in
my
config
and
set
it
to
1.0,
that
should
trigger
some
alarm
bells
that,
like
I,
have
an
insecure,
config
right.
That
might
be
what
I
have
to
do
in
my
environment,
but,
like
I
I
shouldn't
be,
I
shouldn't
be
able
to
do
that
without
having
a
word
like
unsafe
somewhere
in
my
config
and
it's.
But
it's
not
true
that
it's
like.
B
Oh,
it's
not
true
that
it's
always
unsafe
to
us
that
the
min
tls
version,
it's
just
true,
that
it's
unsafe
to
set
it
lower
than
you
know,
1.1
or
1.2,
and
even
that,
like
it's
like
kind
of
a
gray
area.
Right
it
like
depends
a
lot
on
taste
of
preferences,
around
tls
attacks
and
what
you
think
is
plausible
on
your
infrastructure
and
stuff.
B
Okay,
all
right,
I
don't
think
we
have
a
firm,
so
there's
also
a
bunch
of
connection
options
that
we
don't
have
in
any
other
place
yet
around
like
timeouts
or
connection
pool
sizes
or
overwriting
dns
resolution,
and
instead
not
not
necessarily
overwriting
dls
for
dns
resolution,
but
setting
the
server
name
to
be
verified
on
the
tls
search
separately
from
the
connection
endpoint,
which
is
another
common
config.
B
I
see
on
a
lot
of
clients,
not
necessarily
ldap
clients,
but
just
tls
clients
in
general,
so
that
you
tell
that
you
tell
the
tell
the
code.
I
want
you
to
connect
to
ip
address.
You
know
192.168.1.20
and
when
you
connect
there,
I
want
the
certificate
to
say
ldap.mycompany.com,
because
I
don't
actually
have
a
real
dns
record
for
ldap.mycompany.com.
B
B
C
G
The
the
big
one
I
remember
is
dns
based
load
balancing
where
the,
where
the
so
you
have
three
ldap
servers
and
you
configure
your
supervisor
to
point
to
ldap.company.com
and
that's
just
a
dns-based
load
balancer
that
brown
robins
against
the
three,
but
it
like
that.
Each
one
has
its
own
cert
so
like
when
you
try
to
connect
to
it
the
other
one
like
the
first
one
will
predict
ldap1.company.com
and
then
the
connecting
component
will
be
like.
B
G
The
reason
this
came
up
is
this
was
like.
Why
don't
you
support
this
because,
like
this
works
with
active
directory
or
whatever,
like
they're
like
yeah
this,
this
is
very
common.
Do
you
know
space
load
balancing
is
very
common.
You
know
that
I
was
like
okay
sure,
maybe
there's
like
the
way
I
have
gotten
around
in
the
past.
Is
we
had
a
much
more
open-ended
idp
that
was
sort
of
like
a
plug-in
style
idp
so
without
without
with
enough
effort
you
could
hook
in
anything
to
it.
G
B
I
don't.
I
think
I
think
we
talked
about
that
before
and
decided
that
like
we
don't
really
want
to
do
that,
because
it's
a
lot
of
work
to
document,
but
but
I
think
the
point
of
it's
like
I
don't
know.
If
I
don't
know
if
we
would
document
it
like
if
you,
if
you
have
to
pull
that
piece
off
the
shelf,
you
better
know
what
you're
doing
and
you
don't
need
it
most
of
the
time.
G
G
B
B
You
always
have
the
other
fallback
too,
which
is
you
can
always
build
a
custom
copy
of
the
code
that
can
change
if
there's
really
any
default.
Setting
that
you're
really
unhappy
about
you
can
always
fork
the
code
and
like
build
a
copy
with
custom
values
for
custom
deployment,
but
I
feel
like
most
of
the
time
you
wouldn't
need
to
tweak
any
of
these.
C
It
does
not
so
we're
in
our
first
version
we're
not
doing
a
connection
poll.
Every
every
request
opens
a
new
connection
sends
several
ldap
protocol
verbs.
I
think,
but
I
think
that's
pretty
common
with
ldap,
because
the.
C
C
C
G
B
Yeah,
I
I
agree.
It's
fine.
I
don't
think
this
is
good
yeah
if
you're,
if
you're,
if
you're
calling
this
once
per
user
per
day,
you
could
have
a
lot
of.
I
mean
you,
probably
probably
don't
it's
not
it's,
probably
not
fair
to
think
about
it
averaged
over
a
day,
it's
probably
more
fair
to
think
about
it,
like
everybody
in
my
company
gets
online
in
the
course
of
an
hour
or
two
in
the
morning.
So,
however,
many
users
there's
a
good,
it's
be
really
spiky
load
at
particular
times
of
the
day.
B
So
I
also
don't
think
the
latency
is
like
super
critical
right,
because
you're
you're
doing
this
operation
in
line
with
a
very
slow
manual,
interaction
typing
your
password
into
the
console
and
hitting
enter,
and
so
like.
It's
not
something
that
it's
not
something
you
expect
to
be
instant,
except
it's
totally
fine
if
it
takes
a
second
or
something.
G
G
This
is
only
kind
of
related.
I
was
going
to
ask
so
today
for
oidc.
We
don't
do
any
any
checks
when
you
refresh
your
token
against
the
parent
oidc
provider,.
G
Do
we
think
we
can
kind
of
build
all
of
that
generic,
like
some
concept
of
giving
the
refresh
token
that
we
hand
to
the
user
some
kind
of
encrypted
state
and
they
hand
it
back
to
us
and
do
some
validation,
and
maybe
some
refreshing
of
groups
or
whatever,
like
all
kind
of
generically
across
all
idps,
just
with
maybe
some
interfaces
or
something
I
don't
know?
If
I
don't
know
if
that
matters
right
now,
I
was
just
kind
of
thinking
about.
G
C
Ready
right
right
now
we're
using
fossite's
built-in
refresh
token
generator,
so
we'd
have
to
write
our
own,
but
it
lets
you
do
that.
So
it's
probably
not
super
hard
to
do
that.
G
Yeah,
I
guess
I
was
thinking,
does
the
structure
of
the
ldap
code
need
to
be
in
some
particular
way
to
help
us
be
in
them?
Like
I
know
in
the
callback
endpoint
right,
we
could
store
data
if
we
wanted
to.
We
don't
today
for
oidc,
but
we
totally
could
not.
Nothing
prevents
us
from
doing
that.
So
that's
in
that
same
vein.
I
don't
necessarily
have
a
good
sense
for
what
ldap
is
doing
in
that
regard
like.
Could
we
do
something
similar
you
want
to
do
we
have
space?
C
Seems
possible
and
right
now
our
refresh
endpoint
isn't
doing
anything
custom.
It's
it's
pretty
much.
The
default
fosite
refresh
endpoint,
but
we
could
add
custom
code
there.
Of
course,.
B
To
avoid
to
avoid
storage
for
some
of
the
other
for
access
tokens
too,
I
know
that,
like
there's,
there's
some
properties
that
you
only
get
if
you
store
access
tokens
around
like
single
use
and
and
stuff
like
that,
but
all
right
single
use
for
the
auth
codes,
revocation
support
for
access
tokens,
but
I'd
be
interested
in
exploring
the
the
world
where
we
stopped
storing
those
at
all
and
rely
on
the
client,
basically
to
rely
on
keeping
data
and
the
token
itself
encrypted
and
might
be.
B
B
Okay,
I
think
we're
running
out
of
topics-
maybe
maybe
it's
a
good
time
to
move
on
if
anybody
has
any
other
any
other
thoughts
on
the
connection
options
thing
I
dropped
the
issue
there.
If
you
think
of
other
options
that
we
think
we
might
need
otherwise,
does
anybody
have
any
other
discussion
topics.
D
Just
one
other
thing
on
the
ldap,
but
not
on
the
connections,
is
active
directory.
Specifics
is
that
going
to
be
like
global
catalog
or
things
like
that
or
index.
You
need
to
do
member
colon
1.1.,
whatever
it
is
in
order
to
get
the
membership
within
a
group,
because
there's
some
weird
unique
id
that
active
directory
uses
and
a
lot
of
in
you
know
specialties
within
80..
D
So
just
wondering
that
and
nested
groups,
one
of
the
most
common
things
we're
seeing
both
in
uaa
and
dex
is
people
limiting
the
nesting
of
groups
that
you
go
down
in
searches
because
of
the
time
it
takes.
So
just
wondering
those
two
and
the
one
other
thing
I
can
point
out.
That
has
been
an
issue
in
other
idps
in
the
past
with
specifically
has
been
federated
domains.
So
using
forests
with
an
active
directory,
the
idm
of
vmware
has
had
that
issue.
Uaa
has
had
that
issue.
Dex
has
had
that
issue.
D
B
Yeah,
that's
a
good
question.
We've
talked
about
some
of
those
things
before
I
think
some
of
it
we've
sort
of
planned
to
do
later.
B
We
could
then
like
turn
up
some
of
these
features
on,
like,
like
the
forest
support
and
stuff,
like
that,
you
know
on
active
directory
by
default.
B
I
think
we
also
talked
about
like
auto,
detecting
more
things
on
active
directory
at
some
point,
or
I
think
mo
even
had
an
idea
about
in
the
active
directory
case
having
a
flow
where
we
actually
like,
join
the
domain
and
discover
everything
as
a
as
a
like
a
proper
participant,
instead
of
just
trying
to
treat
it
as
a
a
generic
ldap
directory.
G
D
Thereof
of
the
support
right,
exactly
uaa
does
support
it
and
the
idm,
which
are
the
other
two,
that
I've
used
just
frequently
and
both
of
them
do
support
nested
groups
and
have
the
capability
of
saying
how
deep
you
want
the
search
to
go,
because
I've
been
to
environments
where
I've
had
seven.
The
most
I've
seen
was
77
layers
of
nested
groups
and
the
search
time
that
it
took
for
idps
to
do
the
search.
There
was
absolutely
insane,
so
we
limited
it
to
10
and
said
you
know
anything
beyond
that.
Sorry.
D
But
that
is
something
that
you
know.
Dex
is
not
good
at.
G
D
Right,
I've
only
seen
the
nested
groups
used
in
active
directory.
I've
never
seen
them
used
in
an
open,
ldap
or
anything
like
that
environment.
But
I
see
them
used
all
the
time
in
active
directory.
B
G
Pretty
bad,
but
I
have
seen
like
11
in
my
like
11
layers
of
nesting.
Well,
I
guess
that
wasn't
even
true
I
it
was
how
many
layers
are
you
away
from
a
parent
group
that
gave
you
like
admin
rights
on
your
box?
That
was
the
problem.
I
was
solving
at
the
time
and
it
was
like
11..
It's
like
this.
No
one
knows
why
you're
rude
on
your
box
anymore.
It's
just
horrible
sets.
D
Yeah,
no
so,
but
that's
been,
that
is
usually
an
issue
in
the
federation
of
domains
has
always
been.
The
forests
have
been
big
issues
and
idps
in
the
past
with
the
different
domain
names.
I
know
from
unfortunate
experience
at
large
enterprises
where
they
have
large
forests
of
many
many
domains.
B
There's
another
related
topic
here,
which
is
how
how
are
we
going
to
test
all
this
stuff
right
now?
I
think
that
I
think
we
got
a
good
setup
with
openldap
to
make
a
sort
of
a
local
toy
ldap
server,
that
we
can
exercise
all
our
code
against,
but
we
should
probably
start
collecting
requirements
for
what
we
think
our
like
production
scale.
Test
setup
should
look
like.
It
sounds
like
it
should
be:
a
big
active
directory
with
77
levels
of
nested
groups,
perhaps
but
just
in
general,
we
we
also.
B
This
is
us
now,
maybe
also
moving
towards
wanting
to
test
kubernetes
versions
as
one
dimension
that
we
test
across
and
then
as
well
like
idps
as
another
dimension
that
we
test
across,
and
maybe
we
might
need
to
rethink
a
little
bit
of
how
we
structured
ci,
so
that
we
can
avoid
combinatorial
explosion
of
testing
all
the
things
all
the
time.
C
Scott,
you
had
a
really
good
list
there.
I
was
trying
to
capture
it
in
our
agenda,
so
you
mentioned
nested
groups
and
limits
for
that
forests
and
active
directory.
I
think
you
had
one
or
two
more
things.
There.
D
Was
global
catalog
as
well
has
some
uniqueness
to
it
also
around
the
ports,
which
are
different,
but
global
catalog
is
unique.
D
C
So
I'll
be
very
open
with
my
ignorance,
I'm
not
an
expert
active
director
user.
D
Yeah
global
catalog
is
basically
used
again
a
lot
of
times
in
when
you
have
multiple
domains
when
you
have
a
forest,
but
it
allows
you
basically,
it's
a
read-only
endpoint
that
you
can
access
that
then
allows
you
to
access
without
knowing
necessarily
which
domain
the
object
is
located
in
within
that
forest.
B
D
Exactly
yeah
and
that's
basically,
you
only
see
it
in
large
enterprises.
I've
never
seen
it
in
any
small
companies
used,
but
it
makes
just
authentication
much
quicker
when
you
have
over
like
three
or
four.
I
think
the
best
practice
that
microsoft
had
put
out
once
was
like.
If
you
have
more
than
three
or
four
domains
in
your
forest,
then
you
should
use
global
catalog
for.
G
G
D
I
tried
to
ping
the
guy
he
hasn't
answered
me
yet.
I
know
we
had
issues
by
multiple
customers
with
it
in
in
vidm
previously,
and
I
know
that
it
can
be
a
bit
different.
It
has
to
do
with
the
ports
and
just
the
way
that
it
does
the
mapping
of
which
domain
within
the
forest
it
was
in.
So
it
was
kind
of
intertwined
with
the
forest
issues
that
exist
sometimes
of
supporting
multiple
domains
and
that's
where
it
was
kind
of
coming
from.
D
I
will
try
and
again
ping
the
ping,
the
guy
and
I
sent
him
a
message.
The
guy
who
dealt
with
this
from
my
team
and
then
I
can,
you
know,
share
some
more
information
over.
You
know
slack
once
I
get
that
info
from
him.
B
This
is
super
helpful,
scott.
It's
a
really
really
good,
really
good
ground
truth
for
us,
as
we
get
into
trying
to
figure
out
what's
important
to
test
and
support.
B
Well,
does
anybody
have
any
other
last
minute
discussion
topics
to
wrap
up,
otherwise
I
think
we
are
at
time.
A
All
right
thanks
everyone
for
joining
today's
edition
of
the
pinnapen
community
meeting
scott.
I
just
want
to
echo
what
matt
said.
Thank
you
so
much
for
your
knowledge
sharon.
It's
super
helpful
for
the
team
and
I'm
really
looking
forward
to
your
continuous
engagement
with
the
community
and
super
helpful.
A
Our
next
meeting
is
not
until
may
6th,
since
there
are
five
thursdays
in
april
and
we
meet
every
first
and
third
thursday.
So
that
means
we
won't
meet
for
another
three
weeks
and
that's
going
to
be
on
may
6th
and
we
meet
at
9
a.m.
Pacific
time,
12
p.m.
Eastern
time.
So
we
look
forward
to
seeing
you
then
otherwise,
we'll
see
you
on
our
youtube
recordings
thanks.