Authorization model


Wojciech Dec
 

Hi Folks,

here's the initial authorization model, that I would like to propose for starters. Key inputs exected to be provided by the AuthN sub-system are: role and domain-name.
The idea is that the AuthZ system would use these and run an authorization check against the service, designated by service-name, that has triggered the AuthZ action.

The model allows for chaining of authz policies, via an ordered list of references to such policies.

The simple-authorization node is there for demo purposes only - it forms the core domain-agnostic authz policy model, which would be reusable by components wishing to extend it, etc.

module: authorization-data-schema
   +--rw domain-authorizations
   |  +--rw domains* [domain-name]
   |     +--rw domain-name           domain-type
   |     +--rw policies* [service action]
   |     |  +--rw service      service-type
   |     |  +--rw action       action-type
   |     |  +--rw resources    resource-type
   |     |  +--rw role         role-type
   |     +--rw authz-domain-chain* [domain-name]
   |        +--rw domain-name    leafref
   +--rw simple-authorization
      +--rw policies* [service action]
         +--rw service      service-type
         +--rw action       action-type
         +--rw resources    resource-type
         +--rw role         role-type

Yang file attached.

Regards,
Wojciech.


Wojciech Dec
 

Hi All,

given that this is an initial model, I'm collecting your feedback on, and mindful of the fact that Yang syntax might be new to some, here's some additional description.

The Yang model consists of two main data structures:
- A simple Authorization node: This contains the key/basic authorization data model, in the form of a list that is keyed by a "service" and "action". More on these later one
- A domain authorization node: This contains a list of the basic authorizations, but in a per domain form, with the key being a domain. In addition, for each list item, there is an additional list, authz-domain-chain, containing an ordered list of references to additional domain policies that are applicable for this domain.

The "service" data item, is intended to respresent an ODL service component that is effectively invoking an authZ request. Eg, if an authN user, joe@... is making some request via the REST interface, the "service" would be REST(conf). If the same user was doing a request over Netconf, the "service" would be Netconf. Naturally, we need to arrive at some naming convention for services, perhaps bundle names.
The "action" is an item off the enumerated list (crud, none, all) representing the requested action. With this model client would be responsible for mapping their service specific request (eg PUT) to such an action (eg create).

About the Authz chain. The list is user-ordered, meaning that the order of the entries is intended to be set by the writer into that list. I'm thinking that one likely chain would be to actually make this list an explicitly priority ordered list, by introducing a "priority" data item.
The API to the AuthZ service engine is not captured by the above model, but that will be a next step if we agree that the above is a decent base.

Example of an AuthZ chain: Suppose foo.com is using the services of bar.com, who in term use abc.com. Each of the "lower tier" providers would represent their customer policies as customers.bar.com and customers.abc.com.

When joe@... makes a request to read X using service Y, the conceptual AuthZ service engine would use the data from the foo.com entry on the domain-authz list, to evaluate in a first instance the authz for foo.com as key. Finding that this policy contains an ordered list comprised of customers.bar.com and customers.abc.com, each of those policies are retrieved from the domain-authz list (using customers.bar.com and customers.abc.com as key).

Conceptually the data model does not deal with conflict resolution, leaving such processing to the service engine. Alternatively policy conflict resolution  checks could be be applied upon policy insertion. The data model is neutral to which of these methods is chosen.

Welcome your feedback.

Regards,
Wojciech.



On 3 July 2014 17:02, Wojciech Dec <wdec.ietf@...> wrote:
Hi Folks,

here's the initial authorization model, that I would like to propose for starters. Key inputs exected to be provided by the AuthN sub-system are: role and domain-name.
The idea is that the AuthZ system would use these and run an authorization check against the service, designated by service-name, that has triggered the AuthZ action.

The model allows for chaining of authz policies, via an ordered list of references to such policies.

The simple-authorization node is there for demo purposes only - it forms the core domain-agnostic authz policy model, which would be reusable by components wishing to extend it, etc.

module: authorization-data-schema
   +--rw domain-authorizations
   |  +--rw domains* [domain-name]
   |     +--rw domain-name           domain-type
   |     +--rw policies* [service action]
   |     |  +--rw service      service-type
   |     |  +--rw action       action-type
   |     |  +--rw resources    resource-type
   |     |  +--rw role         role-type
   |     +--rw authz-domain-chain* [domain-name]
   |        +--rw domain-name    leafref
   +--rw simple-authorization
      +--rw policies* [service action]
         +--rw service      service-type
         +--rw action       action-type
         +--rw resources    resource-type
         +--rw role         role-type

Yang file attached.

Regards,
Wojciech.