This group is locked. No changes can be made to the group while it is locked.
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.
The model allows for chaining of authz policies, via an ordered list of references to such policies.
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.
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.
| +--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 policies* [service action]
+--rw service service-type
+--rw action action-type
+--rw resources resource-type
+--rw role role-type
Yang file attached.
toggle quoted messageShow quoted text
Welcome your feedback.
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).
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.
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 "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).
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.
- 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.
- 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
The Yang model consists of two main data structures:
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 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.
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.
On 3 July 2014 17:02, Wojciech Dec <wdec.ietf@...> wrote: