directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Triplesec] Permissions, Roles and Groups
Date Thu, 25 Jan 2007 20:39:12 GMT
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?

> 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 

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.


> 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.


View raw message