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