You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Vincent Tence <vt...@videotron.ca> on 2004/06/22 02:21:48 UTC
Re: [Apache Directory Project Wiki] Updated: JanusHome
I have written ideas for Janus on the wiki that I want to experiment in
the following weeks .
In the current code base Authentication is pretty well defined, but I am
not very pleased with the way authorization works. The focus on Role
Based Access Control is too strong and the code cannot accomodate other
security policy needs. I'll be working in the Janus sandbox in the next
weeks to try implement those ideas to hopefully come up with a stable
framework foundation. XML will be my preferred definition language for
proving the concepts.
Then, I plan to add persistent implementations: RDBMS, LDAP, ...
- Vincent
directory-cvs@incubator.apache.org wrote:
> Date: 2004-06-21T21:10:43
> Editor: 24.37.52.157 <>
> Wiki: Apache Directory Project Wiki
> Page: JanusHome
> URL: http://wiki.apache.org/directory/JanusHome
>
> no comment
>
>Change Log:
>
>------------------------------------------------------------------------------
>@@ -7,15 +7,68 @@
>
> Following is a proposed direction to drive the development of Janus.
>
>-==== Terminology ====
>+==== Glossary ====
>
>+||'''Credential'''||Unit of proof of identity||
>+||'''Realm'''||A set of principals and associated credentials and an authentication method||
>+||'''Subject'''||Result of a successful authentication||
>+||'''Authenticator'''||Renders an authentication result - may act on several realms||
> ||'''Resource'''||Object of an authorization decision||
> ||'''Action'''||Operation to be performed on a resource||
> ||'''Permission'''||An action on a associated resource which is the subject of an authorization decision||
> ||'''Condition'''||An expression of predicates on a subject (on its principals)||
> ||'''Rule'''||Definition of an effect of verifying a condition on a permission||
>-||'''Effect'''||Consequence of verifying a rule: permit or deny||
>+||'''Effect'''||Consequence of evaluating a rule: permit, deny, indeterminate||
> ||'''Policy'''||A set of rules and an algorithm for combining rules||
> ||'''Policy Set'''||A set of policies (or other policy sets) and an algorithm for combining policies||
> ||'''Applicable Policy'''||A set of policies and policy sets that apply to a resource||
> ||'''Context'''||A set of environmental attributes that affects an authorization decision||
>+||'''Information Provider'''||Provides information on subject attributes (e.g. groups, roles)||
>+||'''Authorization decision'''||Result of evaluating policies: permit or deny access||
>+||'''Authorizer'''||Renders authorization decision based on policies and or policy sets||
>+
>+==== Control Flow ====
>+Based on the above definitions, the typical flow would be (notice the great ASCII art ;-)):
>+
>+
>+'''Authentication'''
>+{{{
>+ credentials
>+Client ----------------------------> credentials
>+ authentication request ------------------->
>+ Realm
>+ <-------------------
>+ Principal
>+
>+ Authenticator (...might repeat...)
>+
>+ Subject
>+ ------------------>
>+ Information Provider
>+ <------------------
>+ Subject Subject (e.g. with group or roles attributes)
>+ <----------------------------
>+ authentication result
>+}}}
>+
>+'''Authorization'''
>+{{{
>+ Subject + Permission
>+Client ---------------------------->
>+ authorization request -------
>+ | Identify applicable policies
>+ <------
>+
>+ Subject + Permission
>+ ------------------------->
>+ Applicable Policy (or policy set)
>+ Authorizer <-------------------------
>+ Effect (combination of applicable rules effects)
>+
>+ (...migh repeat...)
>+
>+ -------
>+ | Combine policies
>+ <------
>+ <-----------------------------
>+ Authorization decision
>
>
>