[rsbac] Resources and Enhanced Role Compatibility

[Amon Ott]

On Monday, 28. October 2002 13:19, Jörg Lübbert wrote:
> Amon Ott schrieb:
> > RC deliberately has single roles for subjects only. This avoids all the
> > problems with mutual exclusive roles for separation of duty (including
> > uncontrolled flow of information) and keeps the model simpler.
> 
> I don't see why two roles could exclude each other if they would only
> add their rights to each other? If the negative role compatibility was
> introduced then this might become a problem, but having negative role
> compatibility would only be the second step I'd go. I personally am fine
>   if there were multiple roles adding their rights to a main role.

Keeping to a strict hierarchy, we would not have any problem: the subroles 
would just inherit all their parent's rights, but you would still have only 
one role at a time.

The problem comes when you can have two or more different roles out of a 
bigger set of accessible roles at the same time. This is hard to control, if 
you must make sure that some roles may not be active at the same time. The 
RBAC model works like that.
 
> > My paper for the NordSec conference next week discusses this in a 
comparison
> > to RBAC and DTE models. It will be published on rsbac.org after the
> > conference. I already got people saying that RC model is too complex, so I
> > will be very slow in adding more options.
> 
> What would you think about adding a completely new module called ERBAC
> which is based on the RC module? This way the powerful RC module stays
> the way it is without becoming more complex and the other module can
> become even more complex and even more fine grained than RC currently
> is? One could add my idea of negative/positive role comp there + the
> idea about inherited rights to types.
> 
> > Again, it would make the model even more complex. Are you thinking of a 
type
> > hierarchy, where rights to master types are inherited to subtypes as well?
> 
> I wasn't thinking that complicated in that case. Your idea btw sounds
> pretty good (would be something for ERBAC?), but just like my idea very
> hard to implement (and understand). I was just thinking of groups in
> rsbac_menu so that administration and searching through the various
> types becomes more easy (one could maybe do the same for the roles, too).

I would rather make the extra functionality optional in RC to avoid doubled 
maintenance:

- Hierarchical roles: subroles have (one or more) parent roles' rights 
additional to own rights

- Hierarchical types: rights to subtypes are add by rights to (one or more) 
parent type(s).

We might make a config contest for the most difficult RC setup, which still 
works... ;)

Amon.
--
http://www.rsbac.org