directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Fri, 26 Jan 2007 07:01:24 GMT
On 1/25/07, Alex Karasulu <> wrote:
> Ersin Er wrote:
> > On 1/25/07, Alex Karasulu <> wrote:
> >> Hello,
> >
> > Hi,
> >
> > I will extend the discussion using my recent experience with the subject.
> >
> >> I would like to have a discussion on the meaning of these entities in
> >> general and with respect to how they are modeled in Triplesec today in
> >> the trunk:
> >>
> >>    o Permissions
> >>    o Roles
> >>    o Groups
> >
> > These can be extended to the following entities:
> >
> > Policies
> >  Subjects
> >  Rules
> >  Conditions
> Where is this from? Is this SUN's commercialized names for things they
> have in their access control manager?

Well, these are not only SUN's terminology but generic entity
descriptors that needs to be provided by a powerful access control

What we call Users and Roles in Triplesec can be extended to the term Subject.

We don't have anything like Rules, although we must have. We just use
abstract strings as David said. But this is not for controlling access
but for storing abstract permission information.

And Conditions are still a required property. Beyond selecting the
subjects and resources, we may need to satisfy more conditions like
Authentication Level, IP Address, LDAP Filter, Time etc.

These all are also proposed by NIST spec and XACML.

Let me state where Triplesec's simple String permissions sit in my
proposed scheme (well this is not my stuff of course). You may have
different Rule types. One of them may be URL Access Rule. Triplesec
can store this information and work with agents to decide if a client
has access to a URL or not. Basically the agent component in action
here is a Servlet Filter like thing. For Triplesec's simple string
permissions, you may have a Rule named String Permission Rule. In this
case neither the agent nor Triplesec controls any access but just
replies to queries to determine whether a principal (Subject) is
associated with a certain string permission. In this case the
application (resource) itself should "control access" to itself. And
this is what is currently happening in Triplesec.

Sorry for extending the subject more :)


> > Subjects include any LDAP representable (or somewhat more abstract)
> > user group: LDAP Group, LDAP User, Different User Selections based on
> > some filter or bind options etc.
> >
> > Rules are the actions that can be permitted to subjects. The most
> > common rule type is URL Access Rules. In Triplesec's case, the thing
> > supported by this scheme can be named as String Rules. Triplesec does
> > not really control access but only allows it to be queried. (May be I
> > am wrong.)
> No you are right we would need to supply agents that use Triplesec to do
> this.
> A real Access Control server should really take the control
> > of access to the resources it is protecting. The resource in case of a
> > URL Access Rule is a URL for example. An Access Control system should
> > be aware of or should be in contact with the resource it's protecting.
> > This can generally be provided by an agent installed on the resource
> > side without effecting the resource itself.
> Sure.
> > Conditions may depend on the type of Rules or may be generic. For
> > example, you may specify the time period a resource is allowed to be
> > accessed.
> >
> > I will not go on inlining my comments below because I think I have
> > changed the topic a little bit. If what I am talking is far different
> > from Triplesec's model or aims, we ca just ignore them. Or we may
> > merge the schemes as we're discussing.
> No this is not on the topic :) but it is an important topic to have on
> this ML about SUN's access manager terminology and how their stuff
> works.  This will help us build a better mouse trap.  Perhaps you can
> put these kinds of things on another thread.
> Alex


View raw message