Informally specify
Use Cases formally…
Frank Siebenlist
The Globus Project (www.globus.org)
Mathematics and Computer Science Division
Argonne National Laboratory
[email protected]
2
Use Cases and Authorization Policy

Use cases that highlight requirements associated
with authorization policy are often ambiguous:
John as a VP is allowed to access resource abc

The natural questions that arise are:





Where does john come from?
Who issued the VP group membership assertion
Where is this resource, and who is the owner?
Who issued the stated access policy
Need to find the right balance between readability
to communicate the use case, and formality to
minimize the possible ambiguity

Maybe some simple rules and conventions can help
[email protected]
ANL
3
Identity and names




We all understand that there are subjects and resources
and that some form of unique identity attributes are
associated with those that can be used for
authentication and signing/asserting
Without loss of generality, we can use normal “names”
that should be unique within the context of the use case
For clarity, we will add an identifier for the
administrative domain
For example:


frank@anl, hiro@fujitsu, takuya@nec, resource1@acme
Any of these identities can be associated with a
requester, a resource, and any of them is able to
authenticate him/her self, and to sign or assert
statements
[email protected]
ANL
4
Policy, Statement, Issuer, Owner

All policy statements have issuers associated with
them


So have attribute- and identity-assertions
Note that a statement by itself has no meaning
without context:

frank@anl grants hiro@fujitsu the right to fly an
airplane



Who cares what frank says?
How to find out if we should?
We need to identify the owner of, or the
authorization authority for a resource

That identity is the only one who’s statements we
care about concerning that resource
[email protected]
ANL
Resource policy enforcement and
outsourcing policy administration

No matter what policy statements there are, it is
at the discretion of the resource itself to decide
which ones “count” or are relevant


This itself is again policy
Each resource has its own local policy


5
Which ultimately decides on all access
A resource owner can outsource the access policy
decisions to an authorization authority


It delegates the administrative rights to an
authorization authority to manage the access policy
Resource owner resource1@acme grants the
authorization authority authz1@acme the
administrative rights to manage the access policy for
all the resources it owns
[email protected]
ANL
6
Attribute Assertions


Attribute assertions are statements that
bind some attribute to an identity
All attribute assertions have issuers


frank@anl is a member of the “anl-staff”
group according to jay@ibm
(anl-staff, franks@anl)#jay@ibm
[email protected]
ANL
7
Attribute Assertions (2)

Attribute assertions are meaningless without
context

Context is the authorization policy statement as the
policy will be expressed using the attribute value
with the associated issuer.


According to resource1@anl, all requesters with an anl-staff
membership issued by attr-authority@anl, can read the files
on resource1
(nothing personal, but an equivalent anl-staff assertion from
jay@ibm wouldn’t help much…)
Sometimes a central Attribute Authority are used
within admin domains

Like an Authorization Authority
[email protected]
ANL
8
Direct or Transitive “Trust”




There are not too many possibilities: either you
trust someone directly, or you trust someone
because someone else told you you could…
Access policy statement either are expressed
directly on a subject, or they tell you to trust that
subject to express policy for others.
So the only way to allow someone access for
whom you have no explicit policy rules, is to have
policy rules for someone who has…
The use cases should show how fine grained and
what features we need to express the delegation of
rights.
[email protected]
ANL
9
Summary

Use “name”@”domain” for all identities


Always associate an issuer with an attribute assertion


E.g. “john@acme can read abc”#admin@acme
Always associate an owner or authorization authority
with a resource


E.g. (anl-staff, frank@anl)#admin@anl
Always associate an issuer with a policy statement


E.g. john@acme, resource1@XYZ
E.g. admin@acme is the authorization authority for all the
resources in the acme domain
Explicitly state the delegation of rights or “outsourcing”

E.g. “admin@acme gives the admin@XYZ the right to
administer the access control policy for all XYZ requesters
that want to access resource1@acme”
[email protected]
ANL