[Nsi-wg] Plugfest advice

[John MacAuley]

I definitely think we should be doing HTTP basic authentication for security.  If people are up for TLS mutual authentication then I am willing to do the work.

Mary proposed a set of user authorization levels and attribute names if we would like to try a couple.

Attributes

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.

 

 

Supported attributes

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

 

 

 

 

 

 

 

 

 

 

Authorization

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.

 

Supported authorizations

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

 

 


John.

On 2011-08-08, at 6:35 PM, Jerry Sobieski wrote:

> 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110808/3fc1bc47/attachment-0001.html