►
From YouTube: SharePoint Site Collection Level Permissions
Description
In this video, Jeremy Kelley, Microsoft, details the Microsoft Graph org’s permissions scope phase 1 deployment, in a sure to be a multi-phase rollout, of resource-based consent for app development that limits uncontrolled site-wide access to resources. The discussed functionality - Permissions endpoint on sites goes out in this week’s deployment of the Graph schema along with documentation, Permissions Scope is already present in the AAD portal, and Site Enumeration capability is presently available in Graph v1.0 as well.
This PnP community demo is taken from the February Microsoft Graph developer community call recorded on February 2, 2021. https://youtu.be/gwx2c4YJfko
Visit https://aka.ms/M365pnp
Follow us on Twitter https://twitter.com/Microsoft365Dev
B
All
right:
well,
let's
go
through
the
slides
quickly
and
then
we'll
get
to
demos.
So
a
brief
history
of
sharepoint
app
permissions.
Anyone
who's,
you
know
worked
in
building
apps
for
sharepoint.
Probably
already
know
knows
this
stuff,
but
sharepoint
add-ins
classically
could
be
installed
per
site
collection.
B
B
B
We
believe
that,
ultimately,
there
needs
to
be
a
unified
and
consistent
solution
that
works
across
all
of
the
workloads
in
graph,
and
so
I've
been
working
with
philippe
on
the
aad
team
to
really
make
sure
that
if
we
took
this
first
step,
were
we
making
sure
that
it
was
along
the
direction
we
wanted
to
go
long
term
so
that
we
can
get
all
the
things
that
we
want
and
we
think
this
does.
We
think
this
is
a
necessary
first
step.
B
It's
not
perfect,
it
doesn't
solve
all
the
scenarios,
but
it
gets
us
moving
and
will
certainly
enable
a
bunch
of
scenarios
that
are
going
to
be
really
important
for
people
to
start
working
with
so
we're
targeting
application.
Only
to
start
we
talked
about
delegated,
we
will
eventually
get
to
delegated,
but
for
the
particular
things
we
had
in
mind
that
we
wanted
to
get
working
first,
we
felt
that
targeting
app
only
was
going
to
be
the
right
first
first
piece
and
in
this
first
I'm
calling
it
phase
one
for
lack
of
a
better
term.
B
The
solution
kind
of
requires
engagement,
both
from
client
app
developers
and
the
iet
department.
It's
going
to
require
a
fairly
sophisticated
level
of
engagement
with
it
and
you'll
see
why,
as
we
get
to
the
the
demo,
primarily
we
didn't
build
any
ux
around
this
feature,
so
it
requires
actually
using
a
new
graph
api
to
interact.
B
So
this
will
allow
admins
to
control
access
per
site
collection,
as
I
mentioned
earlier,
sharepoint
add-ins
could
go
to
the
list
level.
We
didn't
expose
that
yet
it's
kind
of
in
our
back
pocket
for
when
we
think
there's
a
real
need
for
it.
When
we
start
to
hear
feedback,
it
will
be
something
that
we
could
open
up.
We
haven't
yet
right
now
we're
going
at
the
site,
collection
and
there's
two
components.
B
B
You
need
to
work
with
this,
which
is
the
new
permissions
api
and
the
sharepoint
section.
The
new
endpoints
we
are
adding,
as
I
said,
require
sites.fullcontrol.all
requires
app
only
for
now.
We've
had
discussion
about
whether
we
open
this
up
specifically
for
a
tenant
admin
delegated
permission
as
well.
We
can
add
that
check
if
we
need
to
the
initial
implementation
requires
app
only
and,
as
I
said,
you
basically
have
two
apps
or
n
apps
in
this
scenario.
B
B
B
So
if
you
want
to
get
the
list
of
app
permissions,
you
do
a
get
on
the
permissions
endpoint,
adding
a
new
permission
as
a
post,
and
then
you
can
get
patch
and
delete
the
individual
permissions
by
id,
which
will
come
back
in
the
overall
permission.
Get
the
demo
I'm
going
to
show
today
uses
actually
an
earlier
implementation,
where
we
were
reusing
the
invite
endpoint.
B
If
anyone
was
on
the
tap
call
a
while
back.
Where
I
presented
this,
there
was
some
feedback
there
that
that
wasn't
great.
We
got
the
same
feedback
when
we
went
to
to
our
graph
review,
so
we
decided
to
go
with
the
permissions
object
instead,
but
the
demo
that
I
have
set
up
is
still
using
the
old,
the
old
method,
so
same
concept,
different
endpoint.
B
A
B
So
that
was
kind
of
our
in
the
future.
Yes,
we
believe
that,
in
order
for
this
to
serve
all
the
necessary
audiences,
there
needs
to
be
a
ux
to
manage
this.
For
this
first
release,
there
is
no
ux.
It
requires
you
to
build
kind
of
an
app
management.
That's
why
we
think
this
isn't
necessarily
going
to
work
for
large
isb
scenarios,
necessarily
where
you're
trying
to
sell
a
boxed
product
going
to
your
customer
and
saying
hey.
B
I've
got
this
thing
that
you
can
buy,
but
you
need
to
do
a
whole
bunch
of
work
to
build
your
own
app,
not
great.
The
scenarios
we
specifically
had
in
mind
were
kind
of
enterprise
dev
scenarios
where
you
have
an
I.t
department
and
an
in-house
dev
department
working
together
for
building
line
of
business
apps.
B
I
don't
want
to
call
out
partners
by
name,
but
we
had
some
canonical
examples
of
this
where
you
could
imagine.
You
are
working
both
with
your
business's
customer
data
and
you
want
to
build
an
app
that
only
works
on
your
customer
data,
but
doesn't
have
access
to
your
hr
data.
Your
finance
data
right,
you
have
kind
of
more
siloed
within
your
enterprise
scenarios.
B
In
those
cases
we
imagine
you
will
have
a
better
understanding
of
specifically
which
site
collections
an
app
needs
to
have
access
to.
They
should
map
into
a
fairly
small
set
that
building
a
management
app
for
those
permissions
isn't
too
terrible.
Hopefully
we
will
also
be
able
to
ship
some
sample
code.
That
gives
you
a
starting
point
that
you
can
just
customize
to
your
needs
so
that
everyone
doesn't
necessarily
have
to
write
it
over
and
over
again,
I
don't
have
a
committed
timeline
on
getting
a
sample
app
out
there,
but
it's
fairly
easy
to
work
with.
B
So
that's
the
long
way
to
say
ui
in
the
future.
Today,
it's
app
only-
and
I
think
there
was
another
question
about-
can
you
use
the
powershell
sdk?
That
is
certainly
my
intent
that
we
expect
that
you
know
we're.
We
didn't
end
up
putting
this
on
the
legacy
sharepoint
apis,
specifically,
because
we
thought
we
would
get
a
lot
of
benefit
from
graph
having
the
powershell
sdk
already.
B
A
B
Yeah
my
original
spec
for
the
feature
specified
both
we
for,
like.
I
said
we
wanted
to
get
this
first
bit
out
first,
so
we
had
to
keep
the
scope
fairly
narrow
in
the
fullness
of
time.
We
expect
that
the
means
to
craft
the
policies
by
which
your
your
app
access
is
shaped
become
a
lot
more
advanced
and
we're
working
with
the
aad
team
to
figure
out
which
feature
set.
Does
this
go
with?
How
do
we
express
this?
You
know.
B
Ultimately,
you
want
to
be
able
to
say
you
know
I
want
all
of
the
onedrive
for
business
accounts,
but
not
all
of
the
sharepoint
sites,
and
you
know
stuff
like
that,
or
I
want
only
users
who
are
in
this
particular
security
group
or
who
only
site
collections
that
are
tagged
with
this
particular
label.
All
that
stuff
is
as
asks
we've
heard,
but
in
the
interest
of
getting
a
thing
out
first,
we
didn't
want
to
hold
up
for
the
all-singing,
all-dancing
version.
B
A
That's
great
and
maybe
one
question
before
we
can
go
to
your
demos,
because
we
have
a
question
around
availability.
I
think
we're
going
to
cover
that
at
the
end,
but
as
as
an
application
developer,
your
app
might
have
access
to
multiple
sites.
Do
you
have
a
way
to
actually
get
the
sites
that
you
have
permissions
to?
So
you
can
kind
of
iterate
through
x
number
of
sites.
B
The
way
that
the
permissions
are
stored
doesn't
lend
itself
to
an
efficient
way
for
us
to
tell
you
all
the
sites
kind
of
gory
sharepoint
implementation,
details
that
interesting
to
like
two
people
that
prevent
us
from
really
easily
giving
you
the
full
set,
but
I
think
we
will
need
to
figure
that
out.
Ultimately,
it's
certainly
in
the
back
of
our
head
that
that's
a
thing,
that's
missing
right
now,
right
now,
it's
kind
of
like
I
said
it's
designed
for
a
scenario
where
you
know
up
front
hey.
I
need
to
work
on
these
five
sites.
B
They're
configured
and
both
it
knows
it
and
the
app
developer
knows
it,
and
so
you
can
manage
a
static
list
somewhere
outside
of
sharepoint.
That
is
not
a
perfect
solution.
It's
not
a
great
scalable
solution,
but
it
is
you
know
it's
the
starting
point
and
we
think
there's
enough,
we
think
there's
enough
value
in
what
we
do
have
to
help
people
get
unblocked.
While
we
work
on
the
next
set
of
set
of
things
here,
I
will
share
my
screen.
B
All
right,
so
we've
got
a
couple
components.
As
I
mentioned,
we
have
our
client
app
and
we
have
our
permission.
Granter
app,
you
can
imagine
if
you
haven't
seen
it
already.
This
is
the
azure
portal
with
the
graph
api
permissions,
so
under
application
permissions.
Now,
if
you
come
down
to
sites
you'll
see
sites
dot
selected,
that's
really
the
only
thing
that
your
client
app
typically
will
need
for
this
scenario.
B
If
you
granted
a
broader
scope
access,
it
will
get
the
broader
scope
access.
So
keep
that
in
mind.
Generally,
you
don't
want
to
request
both
a
broad
and
the
selected
scope.
That's
not
great!
If
we
look
at
the
code,
though,
for
kind
of
that
the
client
app
there's
nothing
special
in
here,
all
I'm
doing
is
executing
some
basic
graph
calls.
B
This
app
in
particular,
has
kind
of
come
up
as
I've
been
transitioning
to
the
latest
and
greatest
versions
of
microsoft.identity.web,
so
this
code
works,
but
I
don't
know
if
it's
the
perfect
way
to
do
what
I'm
doing.
I
haven't
gotten
a
chance
to
fully
update.
Yet
this
is
kind
of
making
manual
request
manual
requests,
as
opposed
to
using
the
the
graph
library
which
I
prefer
to
do,
and
once
everything,
ships
and
a
new
version
of
the
client
libraries
are
out,
I
will
update.
B
Basically,
I
have
a
url
here,
which
is
just
saying:
hey:
go
acts
go,
get
the
metadata
for
this
particular
site
and
I
have
two
sites
configured
in
my
demo:
tenant
one
that
we're
gonna
say
we
do
want,
expect
to
have
access
to
and
one
that
we
shouldn't,
because
we've
got
sites.selected
coming
back.
So
the
first
one,
I
think,
is
the
correct
site.
It's
called
company
coms
and
the
second
one
here
we
expect
to
fail
and
it's
called
above
top
secret,
so
we're
gonna
come
over.
B
We
didn't
get
access
to
the
thing
that
we
wanted
to,
but
we
did
correctly
not
get
access
to
the
thing
we
didn't
we
shouldn't
have
access
to.
So
that
means
that,
right
now
we
have
sites.selected,
but
we
don't
have
application
permissions
set
on
the
objects
that
we
need
to
go
get
like
those
sites
have
not
had
our
application
added
to
the
list.
So
if
we
look
at
our
other
app,
so
we've
got
kind
of
our
now.
We've
got
our
it
management.
B
B
So
this
will
have.
I
can
either
grant
read
or
write
or
the
combination
of
the
two
read
and
write,
and
so
I
need
to
actually
ask
the
individual
permission
here
for
its
details
in
order
to
find
out
what
roles
it
has
associated
with
it,
and
then
the
other
method
we
need
to
do
here
is
add
the
app
permission.
B
So
let's
take
a
look
at
how
that
works,
so
we're
going
to
switch
over
here.
I've
got
this
nifty
test
app
we're
going
to
enumerate
all
the
sites
in
sharepoint.
If
you
haven't
played
with
our
new
sites
enumeration
endpoint,
this
is
going
to
use
that
endpoint
to
list
out
all
the
site
collections
and
my
access
token
expired.
We're
gonna
sign
back
in.
B
All
right
here
we
go
site
enumeration,
get
all
the
sites
fingers
crossed
all
right,
so
here's
all
the
site
collections
in
our
demo
tenant.
We
can
see
here
those
two
sites
that
we
were.
We
were
looking
at
the
above
top
secret,
which
we
don't
want
access
to,
and
company
comms,
which
we
do
so
we're
gonna
click
into
the
details
on
company
coms.
This
is
absolutely
pm
driven
web
ux,
there's
a
whole
lot
of
nested
tables.
Here,
don't
be
offended.
B
If
we
go
to
permissions,
I
can
list
out
and
we
can
see
at
the
top
here.
We've
got
an
empty
table,
no
permissions.
So
what
we
need
is
the
app
id
of
the
app
we
want
we're
going
to
give
it
a
name
and
then
just
which
permission
we
want.
So
I'm
going
to
jump
over
real,
quick
grab.
My
app
id
I'll
come
back.
B
B
We
know
that
it
has
read
access
and
it
was
granted
to
this
app
id
that
we
gave
this
title.
The
title
is
really
just
free
form
text,
it's
much
easier.
If
you
make
it
the
actual
name
of
the
app,
we
aren't
doing
a
lookup
on
it.
The
thing
that
really
matters
is
the
app
id
from
the
client
id
from
the
azure
portal,
and
if
I
wanted
to
delete
this
permission
again,
I
could
push
that,
but
we
haven't
actually
seen
this
working.
So
I'm
not
going
to
do
that.
B
Yet
we're
going
to
go
to
our
limited
app,
I'm
using
the
same
tenant
credentials.
So
it
should
just
sign
right
in
wait
for
the
redirect
and
we
saw
before
it
said
we
didn't
have
access
now.
It
says
we
correctly
got
access
to
the
site.
We
should
and
we
failed
to
get
the
site
we
shouldn't,
and
we
can
do
this
just
to
show
that
it's
live.
I
can
go
over
here
and
delete
the
permission.
B
Come
back
refresh
this
page
and
now
it
fails
to
get
the
site
so
real
easy.
I
call
the
permissions
endpoint
to
add
an
object,
add
the
permission
and
I
get
access.
I
remove
it.
It
goes
away
instantly.
So
we
think
this
is
a
big
first
step,
certainly
better
than
granting
sites.fullcontrol.all
to
every
app
that
comes
along.
B
I
can
share
that.
You
know
our
own
I.t
department
has
been
not
granting
a
whole
bunch
of
apps,
because
people
want
to
talk
to
sharepoint,
but
they
don't
have
a
way
to
to
do
this,
so
we
are
certainly
working
with
them
so
that
we
can
adopt
it
internally
for
some
scenarios,
and
I
hope
that
this
is
useful
to
you
in
terms
of
timelines.
As
I
said,
this
should
be
going
out
in
this
week's
deployment
of
the
graph
schema
so
anytime
this
week
early
next
week,
you
should
see
the
permissions
endpoint
on
sites
light
up.
B
B
A
This
is
amazing
thanks
thanks
jeremy.
I
think
you
answered
quite
a
lot
of
the
questions
by
this
last
segment
around
date,
so
everybody
try
graphics,
floor.
You're
gonna
see
that
coming
actually
not
even
graphic
explorer
because
that's
delegated,
so
it's
gonna
have
to
be
app
only
for
that,
but
I
think
we're
gonna
have
this.
There
was
one
question,
maybe
for
you,
jeremy,
and
maybe
you
can
elaborate
just
a
little
bit.
B
It
will,
in
the
future,
include
teams
sites.
Today,
teams
are
not
included
back
when
we
started
the
feature
we
were
making
a
decision.
That
teams
stuff
would
be
managed
through
teams.
Sharepoint
stuff
would
be
managed
through
sharepoint
we've
flipped
that
decision
and
said
no.
We
actually
want
team
sites
to
be
included
in
site
enumeration,
so
that
will
be
coming
shortly.
B
B
The
permissions
object,
I
believe,
will
be
linked
off
of
the
site
object
because
I
don't
remember
if
it's
a
relationship
or
a
property,
but
it
should
just
be
in
line
in
there,
so
we
have
for
those
that
are
familiar.
We
have
something
we
call
our
scan
guidance
which
is
really
about
how
to
do
large
scale,
processing
of
files
in
sharepoint
onedrive,
because
this
isn't
really
ready
for
isvs
and
kind
of
building
those
large
scale
apps,
I'm
not
sure
if
we're
gonna,
if
I'm
gonna
include
it
there.
B
A
It's
going
to
be
synced
with
the
shipment.
Basically,
once
everything
rolls
out,
documentation
will
be
published
and
then
it's
going
to
be
available,
cool
well,
yeah!
Thank
you,
so
much
jeremy.
I
think
this
is
one
of
the
big
moment
for
for
sharepoint
and
graph.
It's
something
that
has
been
asked
so
much
in
the
past
and
I
think,
as
I
see
in
the
chat,
people
are
quite
excited
about
it.
So
I
wanted
to
give
you
a
big
thumbs
up
on
that.
A
B
Work,
I
know
I
keep
wanting
to.
I
have
to
do
some
some
redaction
to
make
sure
my
app
ids
and
other
secrets
don't
leak.
But,
yes,
there's
nothing
super
confidential
about
what
this
app
does.
This
is
basically
just
we
built
it
to
test
site
enumeration
and
I
just
kept
going
from
there
as
we
built
more
and
more
features.
So
there's
a
whole
lot
of
code
here
and
I
want
it
to
be
up
to
standard
before
we
release
it
as
a
sample.
That's.
A
B
Gcc
is
a
good
question:
there's
a
bunch
of
gaps
right
now
with
sharepoint.
We
are
sorting
out
some
publishing
issues
once
we
do.
I
don't
expect
this
to
be
blocked
from
there.
I
don't
know
if
the
I
I
will
have
to
do
a
little
more
research
to
know
if
the
permission
scope
needs
to
go
somewhere
special
for
gcc.