►
From YouTube: A Zero Trust primer for developers – December 2021
Description
This month’s in-depth topic: A Zero Trust primer for developers. Introduces core Zero Trust principles and why developers’ participation is critical in supporting the IT Group’s Zero Trust policy rollouts. Steps a developer can follow for building a good Zero trust ready app are outlined. Notably verifying callers explicitly using the various claims in the token and adopting Continuous Access Evaluation (CAE). Recommendations for enabling least privilege and tips to swiftly recover from breaches. Next step – get this ebook aka.ms/ztdev covering Zero Trust principles. This session was delivered by Kalyan Krishna - Microsoft. Recorded December 16, 2021. Q&A throughout call.
Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube (Developer channel) and https://aka.ms/m365pnp/videos (Community channel)
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
• Next call: January 20th at 9:00am PT
A
Without
us
today,
without
kalyan
krishna
who's
going
to
talk
to
us
about
some
principles
of
zero
trust
for
developers,
but
before
we
get
started,
let
him
introduce
himself
just
a
little
bit
of
logistics.
This
is
a
public
call
that
we
host
every
third
thursday
of
the
month.
So
thank
you
for
joining
us.
We
are
gonna
record
this
call
and
then
we're
gonna
publish
it
on
youtube,
so
you
can
find
it
in
the
url
listed
on
on
your
screen
or
you
can
follow
us
on.
The
twitter
accounts
listed
there
and
then
you'll
see
notifications
about
this.
A
Our
next
call
will
then
be
on
january
20th
right.
So
I
don't
want
to
take
too
much
time,
I'm
going
to
let
kalyan
introduce
himself,
but
please,
let's
have
an
engaging
conversation
be
friendly,
and
if
you
have
any
questions
or
comments,
please
feel
free
to
type
them
in
the
chat
or,
if
you
want
to
mute
yourself,
it's
better.
If
you
can
raise
your
hand
and
then
kalyan
will
ask
you
to
comment
all
right.
B
Hey
thank
you
stephen
again.
Good
morning,
everyone,
my
name,
is
kalyan
krishna,
I'm
a
program
manager
in
the
microsoft
identity,
division
focused
on
our
developer
experiences
and
essentially
guiding
developers
and
independent
software
developers
and
vendors
who
are
integrating
with
various
features
of
our
platform,
including
microsoft
graph.
B
In
this
particular
session,
we
will
be
presenting
a
kind
of
an
introduction
to
xero
trust,
which
is
essentially
a
more
or
less
an
I.t
probe,
focused
initiative
for
developers
as
well.
There
is
a
part
that
developers
play
to
make
sure
that
an
organization
or
the
zero
trust
initiative
in
general
succeeds
for
a
foreign
organization
for
an
azure
id
tenant,
and
we
would
basically
fish
that
out.
C
B
The
first
questions
that
that
we
always
we
almost
always
get
when
when
we
speak
about
zero
trust
to
developers,
is
like
well,
I'm
already
doing
all
of
these
security
related
exercises.
In
my
in
my
in
my
development
process,
I'm
doing
threat
modeling.
We
have
code
reviews,
we
have
penetration
testing.
There
is
an
entire
security
development
life
cycle
that
we
follow.
So
why
should
we
care
about
these
things
and
and
partly
they're?
B
Quite
right
is
because,
if
you
have
following
these
zero
trust
is
not
essentially
a
replacement
of
these
things,
so
zero
trust,
probably
probably
would
be
called
a
referred
to
as
a
subset
of
what
the
security
fundamentals
that
are
that
are
in
practices.
So
one
way
to
look
at
this
session
also
is
that
we
are
going
to
basically
highlight
those
those
practices
in
the
security
fundamentals
that
are
more
specific
to
zero
trust.
Maybe
you're
doing
all
of
them
today
and
you
don't
need
to
do
anything,
but
if
you're
not
we
will.
B
B
B
This
is
where
the
the
developers
role
is
actually
becoming
more
and
more
important.
As
I
said,
any
anybody
who
has
developed
an
application
or
works
with
an
application
that
has
an
implicit
trust
built
into
it,
just
because
it
is
hosted
in
a
certain
network
environment
has
to
start
looking
from
hey.
Do
I
really
know
who
is
calling
my
app?
Who
is
the
user
of
my
application,
who
is
carrying
out
these
operations?
So
this
is
where
the
zero
trust
says
hey.
B
B
The
next
one
is
called
use,
least
privilege
access,
not
exactly
a
brand
new
thing.
Those
of
us
who
have
worked
with
role-based
access,
security
or
workplace
security
groups
and
app
roles.
Essentially,
you
are
ensuring
that
when,
when
a
user
or
an
application
accesses
a
resource-
and
you
are
making
sure
that
they
are
given
just
enough
permissions
to
do
what
they
are
supposed
to
do,
basically,
we
are
advising
zero
trust
advisors
that
you
should
move
from
this
catch-all
scenario
where
everybody
has
access
to.
B
Maybe
everything
or
or
you
are
like
looking
at
things
very
broadly
in
terms
of
hey.
If
I
give
them
access
to
all
of
this
certain
resources,
they
might
just
be
able
to
succeed
to
basically
develop
a
culture
where
we
will
be
looking
at
just
in
time
just
enough
access
where
which
reduces
the
scope
of
abuse,
that
by
a
certain
user
and
application,
we
will
discuss
this
in
more
detail,
how
it
really
translates
for
developers
in
in
the
later
slides.
B
Finally,
this
is
something
that
third
principle
is
called
assume
bridge.
Is
it
some?
This
is
actually
something
quite
new
for
developers.
I'm
not
saying
you,
you
don't
know
about
what
breaches
are,
but
a
lot
of
development
process
do
not
necessarily
are
built
to
work
with
the
assumption
that
breaches
will
happen
and
it's
an
application
there
and
there
are.
There
are
certain
responsibilities
that
a
developer
has
to
carry
out
to
make
sure
that
the
once
once
a
breach
happens
to
their
application.
B
The
data
that
their
application
handles
there
there
should
be
a
way
to
quickly
recover,
find
out
what
what
is
the
extent
of
damage-
and
this
is
one
of
the
areas
which
I
have
found
is
like
sometimes
surprises
developers,
because
it's
not
something
that
most
developers
have
a
habit
of
automatically
thinking
about.
Yes,
there
are
some,
you
know
in
azure,
radio
and
much
in
microsoft.
We
definitely
covered
this.
We
have
been
covering
this
for
years,
but
in
the
general
developer
ecosystem
out
there.
B
This
is
something
that
surprises
developers,
and
this
is
where
we
are
trying
to
build
this
culture
and
incubate.
This
culture
is
where
developers
should
think
about
hey,
irrespective
of
all
the
steps
that
I
take
all
the
steps
that
an
idp
will
take
all
the
steps
that
any
third
party
provider
or
system
or
process
that
you
have
built
will
take.
There
might
be
a
chance
that
my
application
will
be
breached,
is
am
I
ready
for
it?
Am
I
able
is
it?
B
So
when
you
look
into
when
you
start
your
journey
with
azure
80,
remember
this:
there
is
a
lot
of
work
that
goes
into
providing
you
know
successfully,
implementing
zero
trust
and
irrespective
of
whether
you
work
with
azure
id
or
any
other
identity
provider,
lot
of
this
work
will
be
provided
out
of
the
box
by
the
identity
provider
themselves.
So
I
have
picked
up
just
one
example,
which
is
our
identity
protection.
B
A
lot
of
this
verify
explicitly
least
privileged
access
and
and
think
so
that
those
principles
are
provided
out
of
the
box.
You
as
a
developer,
you
don't
have
to
worry
about
it.
There
are
a
lot
of
questions
we
get
is
like
hey.
All
of
this
is
already
provided.
Why
should
I
care
about
developers?
Yes,
we
understand
that
there
is
the.
There
is
a
lot
of
heavy
lifting.
B
We
have
provided
generated,
provided
a
lot
of
guidance
to
the
it
pros
out
there
to
roll
out
zero
trust
in
their
organization.
So
what
happens?
Is
that
the
need
for
developers
and
it
pros
to
work
together
is
a
key
thing
that
should
be
understood
when
you
are
working
towards
making
your
application
zero
trust
ready.
So,
while
the
bulk
focus
will
remain
on
it,
professionals,
they
would
be
doing
things
like
enforcing
mfa
for
applications,
or
you
know,
creating
ip
address
ranges
to
block
traffic
from
or
enforcing
usage
of
compliant
devices.
B
These
are
not
something
that
requires
developers
to
do
anything
in
their
app,
but
there
are
certain
things
that
require
you
to
as
a
developer,
to
take
care
of,
because
not
all
of
the
things
that
it
pros
need
to
do
will
to
implement
zero
trust
will
succeed
unless
you
as
a
developer,
take
some
of
them.
So
let's
take
some
examples.
Okay,
so
the
the
first
thing
that
that
comes
to
my
mind,
every
when
we
look
look
at
this
is
credential
hygiene.
B
So
what
happens
is
when
a
breach
happens?
One
of
the
first
things
that
an
id
admin
wants
to
do
is
that
they
want
to
be
able
to
quickly
rotate
your
secrets
and
certificates.
So
if
you
are
not
using
keyword
and
your
application
is
not
really
built
for
it,
the
they
have
to
basically
come
to
you
and
ask
you
to
do
so.
Maybe
do
a
redeployment.
We
don't
want
that.
B
You
should
be
looking
at
developing
your
applications
in
a
way
where
an
it
proven
it
admin
or
department
can
actually
go
and
when
they
detect
some
kind
of
a
breach,
they
should
be
able
to
rotate
your
credentials.
You
know
compromise
credentials
without
your
involvement,
and
this
is
one
of
the
most
common
areas.
B
So
have
you
built
your
app
to
prepare
those
things
you
know
handle
credentialing,
yes
or
no,
because
if
you
haven't
the
id
pro,
the
id
admin
would
actually
fail.
The
second
one
is:
we
have
step-up
authentication
ca
and
some
features
which
require
our
applications
to
specifically
add
support
in
them,
not
all
of
them.
Some
of
these
can
be
in
for
server
side
like
mfa,
but
there
are
some
like
step-up
authentication
that
we
will.
That
requires
you
to
write
some
code
on
your
site
to
handle
it.
B
Otherwise
all
of
these
efforts
from
it
would
not
really
succeed
fully.
Similarly,
as
more
and
more
data
access
visibility
in
data
access
is
is
coming
up,
like
you
know,
we
are
building
features
where,
and
I
t
admins
or
I
t
pros,
can
I
t
departments
can
see
what
kind
of
permissions
is
held
by
which
kind
of
applications
what
kind
of
data
they
are
accessing?
B
What
kind
of
changes
to
data
they
are
doing,
the
the
it
admins
are
becoming
so
so
the
id
departments
are
becoming
slowly
very
careful
about
what
kind
of
permissions
they
consent
to.
So
in
this
case,
if
you
have
not
built
your
application
to
basically
work
with
the
least
amount
of
permissions
that
your
app
needs
to
succeed,
you
will
find
that
the
the
adoption
of
your
application
will
slowly
become
harder
and
harder.
So
there
are
other
things
like
legacy
protocols
and
api.
B
B
Going
forward
so
as
I
basically
the
these,
not
all,
policies
can
be
can
be
implemented
unless
developer
supported.
You
need
to
help
the
it
process,
because
you
need
to
with
this.
This
initiative
is
because,
if
you,
if
you
work
together,
if
you
support
some
of
these
things,
that
we
are
asking
you
to
do
in
particular
with
your
applications,
you
would
minimize
the
probability
of
you
know,
compromises
happening
and,
most
importantly,
quickly,
respond
when
an
attack
is
in
play,
is
underway
and
basically
reduce
damage
by
saving
your
data.
B
So
as
a
developer,
when
you,
when
you
just
had
your
app
in
in
your
in
your
own
environment,
it
was
just
about
you
and
your
app
and
and
if
things
go
in,
went
bad,
it's
just
your
app
that
that
basically
was
was
at
risk.
What
is
happening
is
when
you,
when
you
deploy
your
application
in
in
a
cloud
infrastructure
like
azure,
the
attackers
are
basically
using
one
weak
app
to
make.
You
know,
move
laterally
through
the
system.
B
It's
not
just
if
somebody
has
compromised
your
client,
secret
or
or
certificate
they
would
just
have
be
able
they
probably
would
only
and
only
damage
or
hurt
things
that
your
application
is
is
is
responsible
for
those
those
can
be
used
for
the
attackers.
Actually,
the
attackers
are
using
it
to
move
laterally
through
the
systems,
compromise,
other
apps
and
so
on
and
so
forth.
So
your
system,
your
cloud
infrastructure,
is
as
only
as
secure
as
the
weakest
link,
and
you
don't
want
your
app
to
be
the
weakest
link
here.
B
So
we'll
talk
about
this
zero
trust
readiness
in
in
more
detail
before
we
stop
for
a
question.
I
just
wanted
to
call
out
that
this
is
this
guidance
that
we
are
going
to
provide
here
is
essentially
for
developers
who
are
integrating
with
our
identity
platform.
This
is
a
good
slide
that
explains
the
general
features
and
libraries,
endpoints
and
user
accounts
that
that
basically
comprise
the
identity
platform.
Our
guidance
is
is,
is,
is
just
gonna
be
limited
to
those
those
those
apps.
A
B
D
B
A
B
It
is
available
I'm
going
to
just
cover
it
in
a
minute.
It's
actually
the
next
topic
that
I
will.
This
is
the
most
important
bit
that
we
want
to
cover
here
style.
If
you
could
hold
your
questions
till
I
finish
up
and
then
I'll
stop
again
and
and
and
we'll
check.
If
that
we
got
to
answer
your
question.
A
A
B
B
Okay
cool,
so
we
get
to
the
meat
of
the
session
how
to
make
your
app
zero
trust
ready
before
we
go
forward.
I
go
forward
on
this
path.
Just
remember
this
is
that
the
zero
trust
implementation
is
it's
not
it's.
It's
not
done.
The
guidance
is
still
evolving.
We
are
learning
new
things,
attacks
keep
happening,
the
attackers
find
new
ways
to
to
compromise
systems
and
we
keep
learning.
We
keep
updating
these
this
guidance.
So
one
of
the
things
that
you
should
notice
is
like.
B
Yes,
there
is
a
set
of
guidance
that
you
will
get
us
from
today.
You
will
incorporate
some
or
most
of
it
in
your
in
your
development
life
cycles,
but
please
check
back.
Let's
say
you
know
six
months
a
year
from
now
as
well,
because
things
will
would
have
updated
a
little
bit
more
depending
upon
how
many
prices
or
how
many
ways,
how
many
new
ways
attackers
will
find
a
way
to
compromise
systems,
especially
in
the
in
the
cloud
ecosystem.
B
One
place
where
you
should
be
you
should
have
bookmarked
is
essentially
our
zero
trust
guidance
center.
We
have
a
specific
section
on
there,
just
just
focus
on
developers.
This
is
the
link
here.
I
will
drop
the
entire
deck
in
the
chat
window
for
anybody
to
share
to
basically
refer
to.
There
are
a
lot
of
links
here
and
we
want
you
to
go
through
them
and
keep
yourself
updated.
B
There
is
a
developer
guide,
which
is
essentially
a
set
of
steps
that
developers
can
take
with
microsoft,
identity,
platform
and
and
those
are
in
the
in
in
this
guide
here
that
we
have
provided
a
link
again,
we
will
be
covering
some
of
the
steps
that
we
have
advised
you
in
the
in
the
developer
guide
in
this
particular
session,
but
if
you
want
the
entire
set,
please
download
the
ebook
and
and
go
through
all
of
it.
Okay,
let's
move
on
so
from
the
prescriptive
guidance.
B
We
will
not
be
able
to
cover
everything,
so
we
have
picked
up
a
set
of
things
that
we
believe
are
the
most
important,
the
most
critical
ones
that
developers
should
pay
attention
to.
So
we
will
basically
start
with
some
general
prescriptive
guidance
for
applications
in
general.
Then
we
will
cover
the
continuous
access
evaluation
in
a
bit
of
a
detail.
B
I
was
and
then
a
small
set
of
guidance
for
those
of
you
who
are
building
more
mobile
applications
that
authenticate
with
azure
id,
and
then
we
will
discuss
lease
privilege
for
apps
and
apis
if
you're
a
web
api
developer.
You
should
definitely
pay
attention
to
this
and
then
we'll
talk
a
little
bit
about
credential
hygiene
and
how
to
basically
enrich
your
logging
or
telemetry
using
some
of
the
data
that
azurity
provides
mean
tokens
and
such
and
then
some
prescriptive
advice
on
how
to
quickly
recover
from
breach
again.
B
There
is
a
much
comprehensive
list
of
things
that
we
are
hoping
developers
would
pay
attention
to.
The
developer
guide
covers
them
all.
This
is
a
very
small
subset.
Okay,
so
the
guidance
that
we
will
provide
here.
We
have
broken
it
kind
of
divided
it
into
the
under
the
three
principles
and
not
everything
actually
fits
one
principle.
B
Really,
not
every
a
guidance
fits
one,
just
one
principle
usually,
but
let's
not
get
very
pedantic
about
it
and
move
on
if
you
are
working
with
azure
ad
in
general,
much
of
the
features
or
new
features
that
we
are
developing,
especially
to
address
zero
trust.
Scenarios
are
available
to
applications
who
use
open
id,
connector,
oauth,
2
or,
if
you're,
using
an
erlang
or
themselves,
especially
the
msr
library.
B
Those
of
you
who
have
not
really
very
familiar
with
the
whole
idea
of
a
modern
authentication
protocol,
so
modernism
they're,
like
you
know,
saml,
is
actually
a
modern
authentication
protocol,
but
unfortunately
it's
kind
of
closed.
So
most
of
our
our
changes
are
essentially
riding
on
the
open
id
connector
knowath
2..
B
So
if,
if
you
are
using
these
two
protocols,
you
would
find
it
much
easier
to
ingest
things
like
continuous
access,
evaluation,
not
context
and
all
the
new
things
that
we
have.
We
have
a
lot
of
new
things
lined
up
to
make
your
application
more
secure,
more
zero
trust
compliant,
but
they
are,
I
would
say,
kind
of.
Unfortunately,
they
have
not
been
able
to
push
it
to
other
protocols.
B
They
will
only
be
available
for
if
you
are
using
these
two
again
also.
The
fact
is
that
these
two
protocols
keep
evolving.
There
is
an
active
community
out
there,
which
is
adding
new
things
to
this
protocol
and
that
basically
makes
things
easier
for
us
to
build
newer
features
and
roll
it
out
to
you.
B
So
it's
something
that
you
should
consider
very
carefully
that
if
your
application
needs
to
you
know
be
super
zero
trust
compliant
in
the
modern
world,
it's
probably
a
good
time
to
look
into
the
amsa
libraries
and
our
or
basically
any
third-party
library
that
is
an
oauth
to
an
open
id
connect,
compliant
amsa
libraries
once
quick,
slider
they're
available
for
various
platforms.
If
you
use
them,
you
are
basically
gonna
cut
out
cut
off
cut
out
your
work
by
you
know,
factor
of
hundreds.
B
There
is
so
much
that
we
automatically
do
for
you
they're
available
for
various
platforms.
Please
have
a
look.
Try,
try
our
code
sample,
see
if
you
can
give
it
a
shot
and
and
make
work
a
lot
easier
for
you.
The
other
aspect
that
you
should
also
understand
is
that,
as
things
evolve,
as
we
add,
new
features
and
solves
will
will
be
updated
to
in
just
the
automatically.
So
all
you
have
to
do
is
to
keep
updating
the
library-
let's
say
every
six
months,
and
you
are
your
application
just
by
doing
that.
B
Your
application
gets
a
lot
of
our
good
goodness
just
out
of
the
box.
So
here
is
some
example.
They
actually
other
than
the
identity
provider
azure
id
itself.
The
m
cells
actually
do
a
lot
of
heavy
lifting
for
you
as
well,
and
if
you're
not
doing
if
you're,
not
using
a
standard
library,
then
you're,
probably
looking
at
a
lot
of
work
out
on
your
plate,
to
do
to
take
care
of
okay.
B
B
B
So
one
example
is
that
you
sign
in
a
user,
you
get
a
token
for
microsoft,
graph
or
azure
rest
api.
Now
these
tokens
have
a
lifetime
there,
valued
from
one
hour
to
24
hours,
depending
upon
how
the
how
things
are
set
up
in
a
tenant.
What
if
the
user
has
their
account
compromised
and
they're
marked
as
risky?
Your
application
is
still
using
that
valid
microsoft
graph
token
to
carry
out
operations
on
behalf
of
this
user,
and
this
is
the
primary
problem
that
we
are
trying
to
solve
with
ca
among
some
of
some
other
things
now.
B
The
challenge
with
this
is
that
we
cannot
just
reject
the
valid
token
just
like
that,
because
it
will
break
millions
of
applications
that
were
built
before
cae
camera.
As
a
developer,
you
have
to
explicitly
add
support
for
cae
in
your
app
now.
Ca
is
a
topic
in
itself
and
I
hope
to
do
a
detailed
session
with
a
demo
one
day,
but
for
now,
if
you
are
interested,
there
is
something
about
making
your
application.
B
What
we
refer
to
as
a
capable
client
and
then
use
cae
start
to
basically
react
to
ca
events.
This
is
a
good
example
of
how
cae
works
behind
the
scenes.
So
let's
say
you
are
a
ca
capable
client,
which
is
your
application.
Okay,
your
application,
if
you're
using
the
amsa
library
you
would
not,
this
is
abstracted,
but
let's
say
you
know
about
refresh
tokens
and
access
program
so
like
for
every
certain
after
certain
interval,
you
will
basically
send
the
refresh
token
to
azure
id
and
azure
id
will
give
you
a
new
access
token.
B
B
Disabled
revoked
will
actually
tell
microsoft
graph
that
there
is
an
application
out
there
with
a
token
for
a
user
who
has
been
found
to
be
risky
in
this
case,
when
your
application
sends
this
access
token
to
microsoft,
graph,
which
is-
and
this
is
a
still
a
valid
access
token
microsoft
graph-
will
reject
this
seemingly
valid
access.
Token.
B
In
those
cases,
your
application.
Now
you
have
done
one
thing
which
you
have
declared
yourself
to
be
ca,
capable
client,
your
application
has
done
so
you
actually
will
get
a
certain
type
of
exception.
That
we
have
documented
here
in
the
akms
claims,
challenge
and
you're
supposed
to
redirect
the
user
back
to
azure
id
for
further
processing,
so
user.
My
azure
id
might
ask
the
user
to
do
an
mfa
or
they
might
ask
the
user
to
change
their
password
or
might
just
block
it.
B
If
things
cannot,
there
is
nothing
to
be
done,
but
the
idea
here
is
that
the
user
is
now
blocked
from
that
user.
Account
cannot
be
used
for
any
more
attacks
or
explorer
vulnerabilities
in
a
system.
So
I
was
hoping
to
do
a
ca
demo,
but
it
actually
takes
quite
a
while
so,
but
we
do
have
a
recorded
cae
demo
in
this
available
in
this
particular
link.
If
you
could
kindly
type
it,
you
should
be
able
to
go
through
it.
B
It's
a
it's
about
five
minutes
or
so,
and
it
will
show
you
how
it
works
for
an
application.
So
again,
once
you've
gone
through
the
demo.
Just
to
tell
you
what,
as
an
app
developer,
you
need
to
change
now,
I'm
basically
referring
to
a
developer,
who
is
using.net
and
for
now,
if
you
are
using
our
identity,
web
libraries,
microsoft,
amsa
libraries,
all
you
have
to
do
in
your
application
to
declare
yourself,
as
capable
of
you
know,
handling
ca
events
is
to
add
this
line
of
code
in
your
configuration
file.
B
I
know
not
all
of
you
are
familiar
with
it,
but
again
I
I'm
repeating
this
go
to
the
claims
challenge,
link
that
I
had
provided.
If
you
are,
if
you
want
to
understand
how
it
works
internally,
but
if
you
are
using
our
libraries,
all
you
have
to
do
is
to
drop
the
client
capability
string
here
and
in
your
code.
B
B
We
see
here
that
if
we
receive
this
exception
from
graph,
which
basically
says
continuous
access
evaluation
resulted
in
a
claims
challenge,
you
will
use
the
consent
handler
again
it's
the
thing
that
is
provided
in
the
library
itself
to
basically
take
the
user
back
to
azure
id.
So
that's
what
the
challenge
user
method
does.
There
is
again
I
stop
here,
because
there
is
a
lot
here,
but
generally
you
should.
B
If
you
are
interested
in
exploring
deeper,
how
cie
works
please
start
with.
If
you
want
really
deep,
you
can
start
with
the
claims
challenge
document
and
see
how
client
capabilities
and
and
exceptions
are
essentially
thrown
at
you.
You
can
try
this
demo.
You
can
try
this
sample
to
basically
recreate
that
scenario.
You
can
use
a
tool
like
your
hybrid
advisor
use,
a
fiddler
to
actually
see
the
challenge
how
it
flows
through.
B
And
so
on
and
so
forth,
all
you
care
about
is
that
there
is
a
new
exception
type
with
a
message
and
there
are
a
couple
of
new
classes
that
will
take
care
of
this
problem,
for
you
handling
handling
your
ca
challenge.
So
I'm
gonna
stop
here
again
and
just
quickly
go
through
some
questions,
because
this
is
actually
the
most
important
bit
that
we
wanted
to
cover
in
this
session
and
make
sure
that
you
are
aware
of
it
and
you
and
as
we
hope,
you
are
basically
going
to
update
your
applications
to
support
it
as.
B
So
I
know
there
is
another
topic
that
I'm
supposed
to
do,
but
I'll
just
stop
here
for
a
second:
do
we
need
to
hard
code,
the
secret?
No,
you
shouldn't.
We
do
it
in
our
samples,
but
in
our
samples
we
also
have
a
link
in
the
bottom,
which
basically
tells
you
how
to
deploy
it
in
azure
and
in
fact,
in
this
particular
sample.
Here
we
have
shown
you
how
to
actually.
B
There
is
a
demo
that
I'll
share
link
in
the
in
towards
the
end
of
this
session,
where
we
show
you
how
to
move
this,
the
secret
from
here
to
key
vault
and
access
it
using
manager
identity.
But
for
when
samples
are
like,
you
know,
we
want
the
developers
to
start
learning
and-
and
we
want
it
to
be
a
little
less
frictionless,
but
we
definitely
have.
Our
advice
is
that
you
should
never
keep
any
secret.
You
know
in
a
configuration
file
thanks
for
calling
it
out
so
question
from
style
is
continuous.
B
Actually,
if
your
token
issued
to
a
custom
api
with
azure
id.
So
here
is
the
point
you
have
it's
a
very
good
question
style.
Today
we
have
ca
events
ingressed
by
just
microsoft,
graph
and
azure
rest
api
by
mid-2022.
It
should
be
available
in
some
fashion
for
anybody.
So
if
you
are
an
api
developer,
you
should
be
able
to
get
a
event
from
azure
80.
B
You
basically
should
be
able
to
say
your
application
should
be
able
to
declare
itself
as
a
cae
capable
server
and
start
receiving
events
from
azure
id,
maybe
not
mid
2022,
but
but
some
somewhere
in
that
year,
but
not
today
today,
it's
more
about
hey.
My
application
is
a
heavy
user
of
graph
and
or
azure
apis,
and
I
want
to
start
basically
taking
those
steps
to
make
my
application
capable
of
handling
these
events.
B
Again,
you
can
write
this
code.
It
doesn't
hurt
to
be
there
tomorrow
if
there
are
apis,
we
support
it
and
a
lot
of
these
resources
start
supporting
ca
in
and
rejecting
tokens.
You're
already
good
for
your
application
is
good
for
the
future.
Here.
The
question
here
is:
do
you
have
any
published
guidance
to
use
certificates
instead
of
secrets
there
in
the
in
the
in
the
dev
guide
that
I
had
provided
a
link
for
we
have
a
section
describing
why
you
should
use
it,
how
you
should
use
it
and
so
on?
B
Thank
you
for
that
comment
about
you
know
using
demo
as
a
best
practice
arc
eric
I'm
just
going
to
scroll
a
little
bit
further
up.
Okay,
another
one
from
silence
is
a
company
portal
of
our
microsoft.
Authenticator
have
required
to
be
installed
on
the
mobile
to
have
sso
to
all
other
apps
installed
on
that
mobile
server
same
idp.
B
There
is
a
lot
to
really
get
into
it,
but
if
you,
if
you
are
using
authenticator-
and
let's
say
there
are
100
applications
that
are
basically
signing
into
that
azure
80
tenant
and
they
are
all
using
msol,
the
the
great
thing
is
that
the
user-
you
basically
set
up
your
account
once
with
your
authenticator
app
and
that's
it
you're
done
every
other
app.
That,
basically,
is
looking
for
you
to
sign
in
will.
They
will
go
to
authenticator.
Authenticator
will
sign
them
up.
B
B
There
is
the
very
interesting
topic
that
I
wanted
to
cover
in
detail,
which
is
around
the
verify
explicitly
side
of
things.
Is
that
it's
great?
If
you
trust
azure
ad,
that
hey
I've
integrated
my
app,
I
dropped
msr
libraries
and
awesome,
I
get
my
authentication
done
and
the
am
celebrator
do
a
lot
of
other
heavy
lifting
as
well,
but
the
principle
of
verify
explicitly
wants
you
to
actually
see
if
there
are
scenarios,
if
your
business
needs.
B
If
your
authentication
and
authorization
needs
basically
put
us,
I
need
you
to
go
a
little
bit
further
than
simply
implicitly
trusting
the
fact
that,
as
you,
ready
was
able
to
successfully
authenticate
a
user
again,
this
might
or
might
not
apply
to
all
of
your
application.
But
you
should
be
aware
of
the
fact
that
you
can
actually
do
much
granular
much
deeper,
much
clearer
decision
making
process.
If
you
are
aware
of
what
claims
are
provided
in
in
like
like
in
this
case,
there
is
a
sample
id
token
from
an
application.
B
That's
just
authenticated
a
user,
and
I
will
cover
some
of
those.
Maybe
you
need
them.
Maybe
you
don't
but
be
aware
of.
It
is
because
there
will
be
times
when,
when
this
is
something
that
you
would
probably
want
to
use
in
your
application,
once
a
user
signs
in
to
drive
some
some
other
business
decisions
in
case
you're
wondering
the
one
of
the
claims
that
you
should
be
aware
is
called
audience.
B
D
B
D
B
You
sorry
before
we
discuss
the
claims.
In
the
token,
if
you're,
using
msal
or
one
of
the
libraries,
usually
the
libraries
will
discard
the
id
token
and
they
will
hydrate
the
claims
in
in
some
kind
of
a
class
or
or
a
base
class,
for
example,
if
you're
using
asp.net
these.
These
claims
are
essentially
hydrated
into
what's
referred
to
as
a
claims
principle
or
http
context.current.identity.
B
B
You
can
look
at
which
statement
that
the
token
was
issued
from
you
can
use
security
groups
if
you
want
to
use
them,
as
you
already
have
the
capability
to
send
these
security
group
ids
that
this
user
belongs
to
in
the
token
itself,
and
you
can
use
it
to
drive
for
their
decisions
if
needed,
name
and
preferred
username.
I
call
them
out
here
is
because
these
can
change
a
lot
of
people
think
this
is
a
primary
key.
It's
not.
B
D
I
mean
we
were
just
at
the
point
of
looking
at
how
we
would
approach
this
at
scale
with
automation
when
we
found
that
the
feature
wasn't
being
delivered
so
that
that
kind
of
stopped
us
a
bit,
because
we
know
we
were
looking
at
how
we'd
manage
this
for
client
level
keys
when
we
don't
have
that
and
we're
sort
of
managing
a
key
pair.
Basically,
then,
obviously,
that
changes
how
we
get
to
look
at
that.
B
Yes,
there
is,
there
is
some
good
discussion
on
this
topic
on
the
link
that
I've
shared
in
the
bottom
aka
scientific
tokens,
how
to
uniquely
identify
a
user.
There
is
also
the
subject
claim,
but
it
has
some
nuances.
I
will
not
cover
it
in
this
particular
session,
but
do
read
read
about
it
in
the
id
tokens
talk
out
there
great
so
yep,
that's
the
only
immutable
identifier
when
you
use
that
again,
applications
can
have
app
roles
great
for
our
back.
B
B
B
This
information
can
be
provided
to
you
right
in
the
token
itself,
if
you
are,
if
you
are,
if
your
business
needs
are
such
now,
this
was
the
token
issued
to
what
we
refer
to
as
a
home
user,
so
user
is
actually
home
in
this
particular
tenant.
Remember
that
your
applications
can
also
be
signed
in
by
guest
users.
Users
were
not
homed
in
the
tenant,
but
are
basically
from
some
other
tenant.
In
these
cases,
the
tokens
there
will
be
a
claim
called
idp,
which
will
tell
you
where
the
user
came
from.
B
So
if
you
look
at
the
issuer
or
the
tid,
where
the
operation
is
taking
place,
this
is
not
where
the
tenant
ids
are
different.
That's
because
the
user
came
from
a
different
entity.
This
user
is
a
guest
in
this
particular
tenant
and
is
able
to
sign
into
your
application.
This
is
actually
something
we
want
to
highlight
is
because
access
to
guest
users,
sometimes
stumped
some
developers
is
like
hey.
Why
is
this
user
signing
in
this
user
is
not
even
a
member
of
my
tenant?
That's
because
users
can
be
made
guest.
B
Actually,
in
reality,
there
are
more
guest
users
in
most
enterprise
trainers
than
home
users
today.
So
if
you
have
situations
where
you
just
want
to
make
sure
that
you
don't
want
to,
you
want
to
treat
guest
users
differently
or
you
don't
want
to
actually
handle
guest
users
at
all.
Look
for
this
claim.
B
Okay,
one
topic
that
we
continuously
got
some
questions.
We
suggest
if
you're,
a
mobile
application
developer,
try
to
see
if
you
can
use
amsoil
and
some
will
automatically
get
authenticated
app
available.
If,
if
it's
already
present
on
the
device,
it's
really
important
because,
as
it
policy
enforcements,
are
being
done
like
things
like
app
protection
policies,
passwordless
device
enrollment,
you
don't
want
to
have
get
into
those
those
those
as
a
developer
yourself.
B
This
is
something
that
you
can
easily
offload
today
and
we
advise
you
to
basically
see
if
you
can
support
the
msr
libraries
and
by
by
extension,
the
the
authenticator
app
now
there
is,
if
you
cannot
do
that
at
least
look
into
google's
android
samsung
and
apple's
documentation
how
to
use
the
system
web
browser.
There
is
some
some
amount
of
standardization
that
is
happening.
B
B
How
ca
effects?
I
don't
have
an
answer
right
now,
but
I'm
going
to
take
a
note
for
this
and
see
if
we
have
some
documentation
available
once
it's
available
for
developers
out
there
today.
It's
not
gonna
happen
is
because
we
are
only
the
azure.
It
is
only
sending
ce
events
to
azure
api
and
microsoft
graph,
but
I
understand
that
it
will
become
a
problem
if
we
have
a
proxy
and
then
azure,
it
needs
to
cross
that
to
send
an
event
through
what
is
the
serialization
of
token.
In
msall
token
blood
happens.
B
If
you
use
security
organization
in
larger
yeah,
we
do
have
to
balance
that
out
token
bloat
is
there,
but
then
again
we
have
a
maximum
token
size.
If
you
go
and
look
for
our
group
group
sample,
search
for
using
security
group
for
with
microsoft,
identity
platform
or
my
azure
active
directory.
If,
if
there
are,
the
number
of
groups
is
more
than
I
think
150,
we
will
not
send
you
groups.
B
B
You
have
a
very
good
point,
so
using
groups
in
a
token
which
is
valid
for
28
hours
is
is,
is
gonna
miss
that
so
I,
if,
if
I
were
to
do
it,
I
will
basically
set
up
a
notification
for
groups
and
and
rely
on
that,
but
I
think
it's
a
it's
a
binary
choice
in
in
some
ways,
because
unless
your
application
uses
graph
notifications,
how
are
we
supposed
to
tell
you
something
that
has
been
provided?
Even
a
bearer
token
has
changed.
B
So
I
suppose
you
would
be
that's
a
good
point
to
call
out
to
for
developers
to
be
aware
of
that.
You
know
valid
tokens.
Tokens
which
are
valid
for
28
hours
are
are
gonna,
have
some
kind
of
a
stale
information,
especially
if
you
are
looking
at
security
group
memberships
thanks
for
calling
it
out
paul
okay,
we
will
now
go
and
cover
some
of
the
some
of
the
topics
that
come
under
the
least
privileged
access.
B
At
this
point,
it
looks
like
we'll
go
a
little
over
the
hour,
so
I'm
gonna
just
move
a
little
faster
and
skip
a
couple
of
demos
that
I
had
planned,
but
the
first
one
is
that
if
you're
a
web
api
developer,
if
you're
not
already
doing
it,
you
should
be
validating
your
access
token,
using
a
standard,
validation.
Sdk,
it's
a
topic
in
itself.
I
would
again
suggest
go
look
at
our
our
documentation,
for
example
the
akms
validated
tokens
to
make
sure
that
your
applications
are
doing
it.
B
If
you
have
registered
your
application
using
visual
studio,
you
will
then,
and
some
of
that
code
is
generated-
you
don't
have
to
really
worry
much
about
it,
because
this
is
this
code
is
generated
automatically
for
you.
But
if
you're
not
aware
of
what
a
token
validation
is,
then
you
should
be
looking
into
some
of
this.
There
are
scenarios
where
you
would
like
to
extend
token
validation
as
well.
B
This
is
another
topic
that
we
will
go
through
is
if
you're
a
web
api
developer
and
you
provide
access
to
data
behind
behind
the
systems.
There
is
some
guidance
that
we
want
you
to
follow
to
make
sure
that
it
pros
or
tenant
admins
when
they
are
providing
consent
or
access
to
applications
that
that
that
provide
data
via
the
web
apis
have
have
some
amount
of
flexibility
available,
some
some
idea
of
how
to
handle
risk
here.
B
B
So
here
is
a
standard
web
api
registration.
If
you
look
at
it,
it
has
just
one
scope.
If
you
are
familiar
with
again
application
registrations,
you
have
registered
a
web
api.
You
have
been
given
an
app
id
uri
and
usually
by
default.
We
give
you
one
one
of
these
scopes
to
get
started
with
now.
This
is
okay
to
get
started
with,
but
this
is
not
something
that
you
want
to
take
it
to
the
to
the
to
the
it
admins
really
because
it's
kind
of
a
catch-all
permission
and
it
creates
problems
for
them.
B
It's
because
they
really
don't
know
what
level
of
data
somebody
is
getting
an
access
to.
So
what
we
instead
ask
you
to
do
is
think
through
how
you
can
help
the
I.t
admins
evaluate
permissions
by
giving
them
a
set
of
scopes
that
basically
convey
some
amount
of
details
and
risk
that
that
each
each
one
of
these
scopes
contain.
B
So
what
happens
is
that
in
these
cases
an
id
admin
has
more
flexibility,
they
would
love
the
idea
that
hey
instead
of
one
catch
all
permission,
you
have
given
them
some
some
some
granularity,
some
some
flexibility
in
this
term.
So
look
at
microsoft,
graph
permissions,
for
example,
so
you
have
user
dot,
read
basic,
which
basically
tells
the
id
admin.
Okay,
very
low,
privilege
permission.
All
this
application
can
do
is
just
read
some
basic
amount
of
information,
user
dot
read,
write
oops
this.
B
This
application
can
now
actually
change
data
for
the
certain
user,
dot
rewrite
at
all,
very
high
privilege
permission
I
need
to
carry
out.
You
know,
be
more
careful
and
be
you
know,
maybe
take
this
application
developer
through
a
lot
more
processes
to
make
sure
that
if
this
permission
is
given
to
them
to
their
app,
they
they
at
least
have
some
some
strong
security
fundamentals
in
this
place.
So
this
is.
This
is
something
that
we
want
you
to
start
looking
into.
It
really
really
helps
the
iet
program.
D
Example,
I
can
cite:
is
the
office
365
customer
key
and
with
that
we
use
two
azure
subscriptions
with
different
people
that
have
access
to
it
and
two
separate.
You
know
key
vaults
with
different
bolt
uris.
The
primary
difference
there
is
that
that
system
operates
using
two
separate
keys,
and
so
you
know
the
keys
are
generated
with
you
know
from
within
azure,
but
because
they
are
two
separate
keys,
we
don't
have
the
challenges
with
having
to
try
and
deal
with
it.
You
deal
with
the
fact
you
can't
move
those
across
regions.
B
B
So
yeah,
I'm
gonna
just
quickly
skip
them.
Essentially.
What
I
wanted
to
show
you
here
is
that
yep,
you
do
not
wanna
just
go
with
one
scope.
If
you
are
building
an
api,
be
a
responsible
developer,
create
a
set
of
scopes
that
give
give
the
it
administrator
some.
Some
idea
of
you
know
having
control
controlling
your
access
to
you
to
the
data
that's
held
by
your
application
and,
if
you're
developing
scopes,
if
you're
sorry
publishing
scopes,
yeah.
D
So
from
this
thing
stand
that
we
have
that
challenge
of
generating
keys
and
then
putting
them
across
the
two
different
environments,
and
I
guess
the
other
thing
there
is
that
in
in
terms
of
that
whole
separation
of
duties,
because
it's
two
copies
of
the
same
key,
you
can
have
two
different
people
with
with
completely
different
access
it.
But
if
they've
both
got
access
to
the
key,
then
you
know
the
key
is
already
known
to
both.
Whereas
by
having
two
separate
keys,
then
each
person
only
knows
one
of
those
two
keys.
B
Thanks
so
to
continue
on
this
discussion,
so
if
you
are
publishing
scopes,
please,
as
a
one
of
the
things
that
you
should
also
consider,
is
publishing
an
application
permission.
This
is
for
developers
who
understand
what
is
that
then
delegated
and
app
permissions.
The
app
permissions
are
being
requested
more
and
more
because
it
enables
things
like
automation,
microservices
and
some
areas,
and
and
then
your
client
clients,
your
basically
the
clients
of
your
api
will
become
quite
frustrated.
B
There
is
a
good
chance
of
them
becoming
frustrated
if
they
only
see
delegated
permissions
and
not
have
permission.
This
is
again
something
that
developers
microsoft.
Product
teams
in
the
graph
api
are
learning
slowly
is
that
it
gives
them
no
real
advantage
of
just
publishing
delegated
permissions,
because
there
is
always
somebody
out
there
whom
we
basically
end
up
disappointing
if
the
equivalent
app
permissions
are
not
provided
again,
a
quick
walkthrough
of
a
token
that
is
given
to
a
web
api,
it's
an
access
token,
not
an
id
token.
In
this
case.
B
B
This
is
an
access
token
again
for
a
web
api,
but
it's
issued
to
an
app.
There
is
no
user
in
front
of
it
again
make
sure
it's.
The
audience
is
right.
Make
sure
that
if
you
want,
if
you
care
about
the
calling
applications,
client
id
look
at
the
app
id
claim-
and
in
this
case
the
app
permissions
are
given
to
you
in
the
roles
claim
just
be
aware
of
that,
and
you
want
to
basically
drive
your
data
access
decision
based
on.
B
What's
what's
actually
consented
for
so
this
will
only
be
available
when
at
least
in
this
case,
the
tenant
admin
consents
for
them.
Okay,
I
wanted
to
show
some
more
on
geographic
explorer,
but
we
are
out
of
time
so,
but
essentially
I'll
probably
get
back
to
it
after
I'm
done
with
the
last
few
slides
here.
This
is
a
topic
I
will
start
quickly
covering
here.
So
again
I
had
discussed
earlier
as
a
developer.
You
have
to
start
looking
into
that.
Hey
my
application
can
be
breached.
Am
I
really
prepared
for
it?
B
So
in
this
case,
how
you
want
to
go
forward
here
is
that
you
have
put
some
policies,
some
some
thought
in
the
process,
something
that
you
have
added
to
your
app
development
lifecycle,
ci
cd,
that
helps
you
recover
quickly.
So,
first
of
all,
we
have
discussed
in
quite
a
support.
Credential
hygiene.
Can
your
app
actually
deal
with
the
credentials
being
rotated
in
the
in
the
keyword
you
want
to
allow
it
to
rotate
credentials
before
you
be?
B
Without
your
help,
you
should
use
keyword
and
manage
identities
together,
especially
if
you're
you
are
deployed
on
azure
today.
This
really
gets
you
into
a
very
safe
place
and
and
helps
with
credential
hygiene.
Today,
as
I
had
mentioned,
there
is
a
demo
out
there
that
you
can
use
get
to
by
using
the
the
url
that
I
provided
here,
where
you
can
see
how
that
application
that
I
had
just
shown
you
that
we
had
used
earlier
for
ca
that
that
I
had
actually
provided
a
link
to
in
the
ca
section.
B
It
depends
on
the
private.
Some
of
the
organizations
will
have
privacy
settings
that
are
either,
but
you
should
consider
writing
some
of
these
into
your
logs.
The
reasons
are
that
when
the,
when
somebody
detects
an
attack
or
when
an
attack
takes
place
or
somebody
is
notified,
the
id
admin
is
notified
of
an
attack
or
a
breach
and
are
on
an
exploit.
B
This
information
is
extremely
useful
to
actually
figure
out
where
the
attacker
went.
What
are
the
things
they
did?
What
are
the
places
where
they
might
have
heard
the
system
or
stole
data
from,
and
things
like
that,
it's
really
really
hard
to
figure
out
the
extent
of
damage
if
this
piece
of
information
is
not
available
in
your
application,
log
so
think
about
how
you
can
make
use
of
it,
how
you
can
enhance
your
telemetry
to
include
these
pieces
of
information?
B
B
Moving
forward
again,
the
attackers
necessarily
don't
always
just
steal
data.
They
might
actually
change
data,
they
might
actually
delete
data.
They
might
actually,
you
know,
destroy
or
create
problems
for
you.
Do
you
really
have
you
really
ever
backed
up
and
restored
from
your
backup?
Do
you
have
those
things
in
place
or
not
is
something
that
you
should
probably
look
into
again?
B
B
You
do
not
need
to
test
in
your
production
environment
again
that
might
not
be
applicable
to
depending
upon
some
of
the
organizational
policies,
but
by
default
you
should
be
able
to
develop
test
your
applications
in
a
separate
tenant
from
your
production,
and
if
you
are
really
really
careful
about
it,
you
should
be
able
to
build
a
ci
cd
process
that
gets
your
code
once
tested
in
a
in
a
test
environment
deployed
to
production
by
judge
by
the
it
admins
or
the
id
department
alone.
Without
your
help,
without
much
of
much
help
from
you.
B
B
The
first
thing
you
know
is
that
the
user
is
an
authenticated
user,
now
you're
using
the
roles
to
decide
some
operations.
So
maybe
there
is
an
admin
portal
on
your
web
application
and
there
is
a
user
portal
or
maybe
there
are
certain
things
around
approval
processes
and
you
will
use
app
roles
for
those,
so
it
helps
is
because
you
can
basically
build
rbac
within
your
application.
There
are
more
benefits
to
it
and-
and
I
and
those
are
covered
again
in
the
in
the
zero
trust
guide.
B
With
respect
to
when
you
use
approach.
For
example,
there
is
a
feature
in
azure
id
called
a
privileged
identity
management
in
those
cases
at
it,
admin
can
simply
pick
up
the
app
or
one
of
the
one
or
more
of
the
apples
in
your
in
your
application,
and
they
can
drive
a
policy
on
on
the
azure,
decide
themselves
like
hey.
If
somebody
is
assigned
to
this
app
role
and
is
trying
to
sign
in
the
application
they
have
to
do,
you
know
two
levels
of
mfm.
B
Okay,
these
are
some
of
the
developer
resources
that
we
have
available
for
you.
I
know
we
dropped
in
a
lot
of
these
links,
but
there
is
some
out
there,
okay
and-
and
you
can
again
start
from
the
the
primary
guide-
the
first
developer
guide,
which
is
accounts
which
has
consolidated
list
of
all
of
these
links
that
you
saw
here.
B
This
is
this
is
again
something
that
an
I.t
admin
basically
uses
to
drive
a
bunch
of
our
back
decisions.
But
if
you
care
about
those,
they
will
actually
some
of
the
claims,
in
your
token,
will
be
driven
by
how
these
policies
are.
The
abac
policies
are
basically
provided.
So,
if
you
remember,
I
had
mentioned
that
things
like
groups,
not
just
groups,
but
as
your
as
your
ready
roles
also
show
up
in
tokens.
So
there
are
parts
and
pieces
that
that
might
be
useful.
B
Depending
you
know,
there
would
be
some
decision
making
that
might
be
affected
by
by
those
those
claims
being
available.
I'm
sorry,
I
don't
have
a
very
detailed
answer.
It's
a
feature
that
I
need
to
look
into
deeper,
but
yes,
the
azurity
roles
and
some
of
the
features
that
drive
features
on
azure
might
be
affected
by
those,
I'm
not
sure
the
extent
to
which
a
developer
should
worry
about
at
this
stage.
They
all
should
be
concerned
about,
but
hopefully
I'll
have
a
detailed
answer
in
the
next
next
series
that
we
cover
on
this
topic.