Each NSA will base its authorization on the attributes of
the user that signed the request. Requests between NSA’s will be signed by the sending
NSA but will also include an global identity attribute for the request
originator which could be used for authorization or logging. The primary
attributes that will be used for authorization are those of the requesting NSA.
An attribute will consist of a name, which may designate a
class of attributes, and one or more values. It is also allowed for a user to
have more than one attribute with the same name and different values. The
intent is for each user to have only one role, but it is possible to have more
than one. All the authorizations granted by the attributes will be combined in way
to maximize the access.
name |
value |
data type |
globalUserName |
“person”@”institution” |
xsd:string |
institutionName |
user’s home institution |
xsd:string |
role |
AuthorizedUser |
xsd:string |
role |
NetworkEngineer |
xsd:string |
role |
SiteAdministrator |
xsd:string |
role |
NetworkOperator |
xsd:string |
role |
NSA |
xsd:string |
privilege |
SpecifySTPList |
xsd:string |
project |
project user belongs to |
xsd:string |
While each NSA will do its own authorization, if there is no
common agreement on attributes and what authorizations they enable, it will be
hard for inter-domain operations to succeed. Thus for a NSA to support this
profile the following authorizations for each attribute should be supported. The various roles are designed to match the
privileges that a given class of users require. Privilege and project
attributes can be combined with roles to grant finer grained access.
attribute |
resource |
permission |
constraint |
AuthorizedUser |
reservation |
create, provision, release, cancel, query |
only for own reservations |
NetworkEngineer |
reservation |
create |
may specify ordered STPList |
NetworkEngineer |
reservation |
provision, release, cancel, query |
all reservations |
SiteAdministrator |
reservation |
create, provision, release, cancel, query |
reservations starting or ending with a segment in local
domain |
NetworkOperator |
reservation |
query |
all reservations in local domain |
NSA |
reservation |
create, |
may specify globalReservationId may specify ordered STPList |
NSA |
reservation |
provision, release,
cancel, query |
all reservations |
SpecifySTPList |
reservation |
create |
may specify ordered STPList |
Hi all-
With respect to the Plugfest, I need to define the authorization
specifics we will use for all the requests.
The Plugfest guide says we will only have one authorized credential: A
"shaman" is a god - it can do anything/everything.
My intent in the interop was simply to show that basic authorization
*was* being performed in the proper places and consistently across al
implementations: If the shaman credentials are presented, it should
pass authorization. If any other credentials are presented, they should
fail authorization.
I didn't want to push the teams too hard on the particulars at this
time, but perhaps this is easier than I think. We need to define the
sessionSecurity field for the interop.
John, or anybody else,... Any suggestions for a simple test auth field?
Thanks
Jerry
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg