You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Todd from University of Illinois Urbana Champaign reported out on this hierarchy breakout:

Relationships between resources themselves and how best to navigate those relationships.

Started talking about Champaign Urbaba.

Developeing authorization system for networking objects.

Switchers ports routers VLANS

Have database system that contains that for the campus networks.

Need to authorized campus users to query the info they need.

Using groups as grantees

Priv are create, update, read

Q: is there an accepted model for how to assign these priv?

Where should the bus logic reside?

Where is the most appropriate place to put this logic?

How should inheritance and potential collisions be handled?

A lot of what we learned the 1st couple of days of this CAMP was very important.

  • starting off w use cases.
  • Use natural language as much as possible
  • Then identify the main componenets of the auth system
  • What are resources, grantor, grantee, etc
  • Next portion is modeling those relationships
  • Separation of relationships between grantee relations
  • Model that separately from relationships between resources themselves
  • Don't know if we can put things in a strict hierarchical model.

We can put it in a mostly hierarchical model

Getting the resources into a model is important

Talked about having sepearte graphs for grantees and resources

In our situation one of the things we want to assign perm to is network ports and VLANS

So  user can only modify a port if its on a VLAN they have permission to.

SSo 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

Consensjus is to provide those priv to each.. is too much
So model in larger situations.  Assign priv to objects themselves .

Have bus logic navigae the relationships.

How to navigate the inheretance of the priv themselves?

A couple of ooptions.

Depeends on appli situioaton

Priv can be inherited. Resource. From a partent resources
Inheretance computed at runtime
Navigate a permissions treee

OR
Altern solution

Instatntiate all priv for all objects themselves so at runtime don't need to do a lot of computation

But when there's an update then bus logic needs to recalibrate for child objects

1.    its' on query time
and
2 it's on update time

PAUL HILL: From recap it wounds like inhereitiance is applied to resources

In permit inheretence is applied to the scope, not the resource,
It's more about the data:

? or
School hierarchy w courses going up to central schools. Might be a different inheretacne model thatn you are talking about.

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 priv to the network
Priv cascades.

Do ou 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

  • No labels