OSCARS Authorization Policy
Introduction
An authorization decision consists of deciding if an authenticated
entity should be allowed to perform some action on a controlled
resource. In OSCARS an authenticated entity may be a bandwidth user or
a bandwidth reservation service from another domain; the fundamental
resource is bandwidth though the domain, and the fundamental permission
is right to reserve some fraction of the available bandwidth. Since
available bandwidth is a limited resource, some finer control is needed
such as the maximum allowed bandwidth and duration. In addition, some
users of the system needed to request or suggest possible internal
routing for the data path.
OSCARS chose to do attribute-based authorization primarily as a way
of
consolidating authorization policy to make it more understandable to
users and OSCARS administrators and partly in anticipation of
integrating with an external attribute provider such as Shibboleth or
VOMS. An attribute is some characteristic of a user, such as being a
member of some project, a holder of some role, or just his identity as
expressed as a registered user name or x.509 identity certificate. A
user gets the maximum of all the privileges granted to all of the
attributes that he has.
OSCARS is currently a self-contained system that defines who its
registered users are and what attributes each one has. As a result, it
needs to control who may manage users and their permissions, so users
become a controlled resource in addition to bandwidth. A final resource
is the internal topology, since we want control who may view the actual
topology and who may see an abstracted version of it.
The underlying guideline of our design and implementation is to keep
authorization policy and implementation as simple as possible. We have
tried to make the granularity of access decisions no finer than is
actually required, and have defined roles to consolidate sets of
permissions into sets that an actual user would need. Some of our
underlying assumptions are: Most users will get their permissions by
being members of a group/role, rather than by individual grants. The
number of group/roles will be small. The number of resources and
permissions will be small. While the implementation may scale to larger
numbers, the ability of the users and administrators to understand it
will not.
We are currently intending to authorize a reservation that has been
forwarded to ESnet from an adjacent domain based on the attributes
assigned to that domain rather than the end user who is requesting the
reservation. Thus the number of users that must be registered with the
system can remain manageable. The name of the user is included in the
forwarded request, so it can be used for auditing purposes or can later
be used for authorization.
Authorization policy requirements
The following paragraphs list the various actions that we want to
control with respect to the resources that OSCARS controls.
Permissions with respect to users
- see own profile
- modify own profile
- list all users
- see all user profiles
- add/delete a user
- modify any user profile
- grant or remove authorizations for any user
Permissions with respect to bandwidth and reservations
- make unlimited reservation
- make reservation with bandwidth constraint
- make reservation with duration constraint
- make reservation with topology constraint
- list own reservations
- query own reservations
- cancel, modify own reservation
- signal own reservation
- list all reservations starting or teminating at a site
- query any reservations starting or teminating at a site
- cancel, modify any reservations starting or teminating at a site
- list all reservations
- query any reservations
- cancel, modify any reservations
- signal any reservations
(signaling instantiates a reservation
or tears down an established circuit by causing the appropriate
commands to be sent to the routers involved)
Permissions with respect to topology
- view abstract topology
- view real topology
- modify the topology
Policy Implementation
All access decisions are made by one of two methods which are called
from each place in the code that is about to grant some access. Access
policy is stored in a database, and an access decision is made by doing
table lookups based on the requester, the action requested and the
resource. Authorizations may have constraints attached, in which case
the parameters of the request must meet the constraints.
The following tables define the components for authorization:
- users – contains
an entry for each registered user, containing among other things, user
loginId, institution to which the user belongs, certSubject and
certIssuer
- resources – has
three entries: users, reservations, topology where topology is the
information about specific paths and routers.
- permissions – has
five entries: list, query, create, modify and signal
- list – shows
minimum information about a reservation or
user
- query – shows all
information about a reservation or user
- create – allows a
new user to added or a reservation to
be
created
- modify – allows
deletion of a user and modification to a
user profile or cancellation or modification of a reservation.
- signal – allows a
circuit for reservation to be instantiated or torn down.
- attributes – has entries
for attributes on which authorization
is
granted, e.g. OSCARS-user, OSCARS-engineer, OSCARS-admin,
OSCARS-service, OSCARS-operator,OSCARS-siteAdmin. There is an
attribute-type field which is set to group for all these attributes. It
is possible to define explicit user attributes for users with specific
permissions, e.g.
user-david with the attribute type user. So far we have not found
the need for any user attributes.
- userAttributes -
maps userIds to the attributes they
possess
- constraints - The
current constraints that are supported are:
- max-bandwidth (int),
applies to create and modify reservation
- max-duration
(int),
applies to create and modify reservation
- specify-path-elements (boolean),
applies to create and modify
reservation
- specify-gri (boolean)
can a Global Reservation Identifier be
specified
on create reservation
- all-users (boolean),
applies to everything except create
reservation.
- my-site (boolean)
currently applies only to list, query, cancel and modify reservations
- authorization - combines
these elements into a row for each
action that each user is permitted. Each row consists of an attribute
id, a resource id, a permission id and optionally a constraint and
value that
applies to this authorization.
Users may have 1 or more attributes. Attributes are arbitrary strings,
defined in the attributes table, e.g. OSCARS-engineer, Atlas-PI,
CMS-member.
The advantage of attributes is that it allows a set of authorizations
to be crafted which can then be applied to a class of users. Otherwise,
each time a new user registers, he must be given the correct and
complete set of permissions for whatever he wants to do.
With attribute-based authorization, the access check will need to look
up user attributes, then look up authorizations for each attribute the
user has and merge them (take the maximum of the permissions).
Default behaviors
- If a user has no entry in the user table or has no attributes in
the userAttribute table, any attempted OSCARS
access
will be rejected immediately by Oscars:OscarsSkeleton:checkUser or
Servlets:AuthenticateUser
- If no attribute that the user possesses has an entry for the
resource/permission pair in the authorization table, the request is
denied.
- The constraint defaults are intended to be the most common cases,
not
the most restricted.
- If there is no max bandwidth constraint specified, there is
no limit
on the bandwidth that may be requested.
- If there is no duration constraint, unlimited duration and
persistent
reservations are allowed.
- If no all-users constraint is specified, the default is
false (only access to own information is allowed).
- If a my-site constraint is specified access to
information that is site specific is allowed.
- If specify-path-elements is not specified, the default is
false and
no routers or hops may be input.
- If specify-gri is not specified, a GlobalResourceId may not
be
specified by the user, but will be automatically generated by the
CreateReservation code.
Example Tables
We have users alice, bob, ed, david chin and andy. Alice and bob have
all their permissions individually assigned. Ed, chin and andy get all
their permissions from group attributes. David gets most permissions
from groups but has one more added individually.
Note: <ed>,<david>,<chin>, <andy> and
<bob> are
indices
in the users table.
<OSCARS-eng><OSCARS-op>
are indices in the attributes table.
attributes Table
id (int) |
attribute name (string)
|
attribute type (int) |
1
|
OSCARS-engineer
|
group |
2
|
OSCARS-operator |
group |
3
|
OSCARS-user |
group |
4
|
OSCARS-administrator |
group |
5
|
OSCARS-service |
group |
6
|
OSCARS-siteAdmin
|
group
|
7
|
I2-developer |
group |
userAttributes table
id (int) |
loginId (int) |
attribute id (int) |
1
|
<ed> |
<OSCARS-eng> |
2
|
<david>
|
<OSCARS-user>
|
3
|
<bob>
|
<OSCARS-siteAdmin>
|
8
|
<david> |
<OSCARS-admin> |
3
|
<chin> |
<OSCARS-eng> |
6
|
<andy> |
<I2-dev> |
7
|
<andy> |
<OSCARS-user> |
Authorization Table
id (int) |
attributeId (int) |
resource |
permission |
constraint name
(string) |
value (int)
1=true, 0=false |
|
<OSCARS-eng> |
users |
query
|
null
[2]
|
null |
|
<OSCARS-eng> |
users |
modify
|
null
[2]
|
null |
|
<OSCARS-eng> |
reservations
|
list
|
all-users
|
1
|
|
<OSCARS-eng> |
reservations |
query
|
all-users
|
1
|
|
<OSCARS-eng> |
reservations |
create
|
specify-path-elements
|
1
|
|
<OSCARS-eng> |
reservations |
modify
|
all-users
|
1
|
|
<OSCARS-eng> |
reservations
|
signal
|
all-users
|
1
|
|
<OSCARS-eng>
|
domains
|
query
|
|
|
|
<OSCARS-eng>
|
domains
|
modify
|
|
|
|
<OSCARS-op>
|
users
|
query
|
null [1]
|
|
|
<OSCARS-op> |
users |
modify
|
null [1]
|
|
|
<OSCARS-op> |
reservations
|
list
|
all-users |
1
|
|
<OSCARS-op> |
reservations |
query
|
all-users |
1
|
|
<OSCARS-user>
|
users |
query
|
null
[1] |
|
|
<OSCARS-user>
|
users |
modify
|
null
[1] |
|
|
<OSCARS-user>
|
reservations
|
list
|
null
[2]
|
|
|
<OSCARS-user> |
reservations |
query
|
null
[2] |
|
|
<OSCARS-user> |
reservations |
create
|
null
[2] |
|
|
<OSCARS-user> |
reservations |
modify
|
null
[2] |
|
|
<OSCARS-user>
|
reservations
|
signal
|
null
[2]
|
|
|
<OSCARS-admin>
|
users
|
list
|
all-users
|
1
|
|
<OSCARS-admin> |
users |
query
|
all-users |
1
|
|
<OSCARS-admin> |
users |
modify
|
all-users |
1
|
|
<OSCARS-admin> |
users
|
create
|
|
|
|
<OSCARS-siteAdmin>
|
reservations
|
list
|
my-site
|
1
|
|
<OSCARS-siteAdmin> |
reservations |
query
|
my-site
|
1
|
|
<OSCARS-siteAdmin> |
reservations |
modify
|
my-site
|
1
|
Defaults
[1] manage and view only his own user info
[2] unlimited bandwidth and duration, only modify, list, query and
signal own
reservations, not input path components.
Ed is a network engineer. As an
OSCARS-engineer he can make reservations, see, modify and signal all
reservations, can only see and modify his own user information,
and has free rein over the topology. An OSCARS operator can view
everybody's
reservations and can see and modify only his own user
information. An OSCARS user can make reservations of unlimited
bandwidth
and duration, view, modify and signal his own reservations and see and
modify his own user information.
An OSCARS admin can manage all user information, but not see or modify
reservations.
CheckAccess Implementation
The preferred way to implement access control is to isolate the access
checking in one place, called the PolicyDecisionPoint that returns a
permit or deny response and is called by all access control
points (aka Policy Enforcement Points/ PEP) to see if an action is
authorized. The AAA/UserManager class provides two methods for
access checking. The first would be called anyplace where a reservation
is not being modified and the second by createReservation and
modifyReservation.
Standard checkAccess method:
AuthValue
UserManager.checkAccess(String user, String resource, String
permission);
Initialize the return value to DENIED
Lookup user in userAttribute table to get list of all attributes
For each attribute lookup (attrId,resource,permission) in
authorization table.
If deny is returned, continue
If there is no constraint, remember
SELFONLY and continue
If all-users=true is returned, return ALLUSERS
If all-users=false is returned, remember
SELFONLY and continue
If my-site constraint is found remember SITEONLY and
continue
At end of loop check for SELFONLY and/or MYSITE
Return DENIED, SELFONLY, SITEONLY, SITEANDSELF.
checkAccess method called by
createReservation and
modifyReservation:
AuthValue
UserManager.checkModResAccess(String user,String resource,
String permission, int ReqBandWidth, int ReqDuration, Boolean
specify-path-elements);
Start out with
ReturnValue = DENIED
bandwidthOK = false
maxdurationOK = false
specPathElemOK = false.
Lookup user in userAttributes table and get a list of attributes for
this user.
For each attribute lookup and
Authrorization(AttrId,resource,permission)
for the authorization returned
if the constraint is
null
mark bandwidthOK=true and durationOK=true,
and returnValue=SELFONLY
if the constraint is max-bandwidth
mark bandwidthOK= true if reqBandwidth < constraintValue
if constraint is max-duration
mark durationOK if reqDuration < constraintValue
if constraint is spec-path-element
mark specPathElemOK = true
if constraint is all-users
if value = 1 set returnValue = ALLUSERS
if value = 0 set returnValue = SELFONLY
At the end of the attribute list
if bandwidthOK = false or maxdurationOK = false
return DENIED
if specify-path-element= true and specPathElemsOK = false
return DENIED
otherwise return ReturnValue