Todd from University of Illinois reported out on this hierarchy breakout:
Started talking about University of Illinois at Urbana-Champaign.
CASE: Developing authorization system for networking objects such as switchers, ports, routers, VLANS.
Have database system that contains that for the campus networks. Need to authorize campus users to query the info they need. Using groups as grantees. Privileges are create, update, read.
Important Questions Involved
- is there an accepted model for how to assign these priv?
- where should the business logic reside?
- where is the most appropriate place to put this logic?
- How should inheritance and potential collisions be handled?
A lot of what was covered the 1st couple of days of this CAMP was very important.
- start off with use cases.
- Use natural language as much as possible
- Identify the main componenets of the authorization system
- What are resources, grantor, grantee, etc ?
- Next portion is modeling those relationships
- Separation of relationships between grantees and the resources themselves
- Don't know if we can use a strict hierarchical model, but can use a mostly hierarchical model
One of the things we want to assign permissions to is network ports and VLANS. So user can only modify a port if its on a VLAN they have permission to.
So do we combine those things and have port to VLAN relationship or do we have each have the unit and have business logic such as " if user X wants to do something they must have this priv AND this priv" ?
Consensus is to assign priv to objects themselves. Have business logic navigate the relationships.
How to navigate the inheretance of the priv themselves?
A couple of options. Depends on application situation.
Priv can be inherited from a parent resources with inheretance computed at runtime by navigating a permissions tree
OR
Alternate solution
Instantiate all privileges for all objects themselves so at runtime don't need to do a lot of computation
But when there's an update, then the business logic needs to recalibrate for child objects
1. it's on query time
and
2 it's on update time
PaulH: From recap it sounds like inhereitiance is applied to resources In perMIT, inheretence is applied to the scope, not the resource.
It's more about the data:
Todd: in our case you have a layer 3 network and have VLANs that are a part of that. Ports on that VLAN.
Model says this VLAN in this network
Inheretence could be that we assign privilege to the network
Priv cascades.
Do you instatiate priv for all of those things?
Then at query time you canm look at an object in the tree or ?
Paul: our database does the authorization , you can query at any leaf or node.
Todd Im a database developer, I think of what's in the tables and what is returned
Chris: grouper has had some perf problems w computing all of the leafs
So we compute the branches up to the leafes, and we can get a result in one query
But we don't have to have a database full of every leaf
Jon wanted to call attention to a theme that was interesting: expansion of authorization info to make vast decisions.
Didn't know much about grouper or permit coming into this event. And learned there are people trying to do what we wanted to do
In the database may rival the size of the database it is protecting?
Something told me it's wasteful but maybe not.
Authorization just demands resources so you need to put resources to it.
Rl BOB : can't resist piling on: it's all risk management. Expend resources on that or expend resources on news that results from security disaster of no access management