directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [Janus] Status
Date Fri, 17 Dec 2004 23:32:21 GMT
Excellent work Vince and a great summary! 

So we basically have the API for an identity management system here.  It 
works really well with the rest of the cornerstone technologies we have 
for building an IM system: kerberos (kdc) server, change password 
server, and an ldap server.

Alex

Tencé, Vincent wrote:

>Hi all,
>
>Good news! Janus has reached its objectives for a first release. The
>objectives for this first release are to layout the general concepts of the
>framework and to provide sufficient implementations for real usage. Since I
>believe barely anybody knows what Janus is about, I will take a moment of
>your time to try explain what it's all about.
>
>Janus is a security framework, dealing with Authentication, Authorization
>and Accounting concerns. Janus aims to make it easier and cheaper to
>integrate security into an application. With that in mind, a set of APIs and
>common abstractions are provided with a set of default implementations
>(JDBC, Hibernate, LDAP, ...). Of course it's based on a POJO model that
>integrates nicely with most of the IoC containers out there.
>
>Janus is still under heavy development, but we've reached an interesting
>stage where sufficient implementation is provided to use in a real project
>(at least, I believe so ;-)). Currently, it's weighting over 100+ classes
>with around 50 classes for test. Here's a list of what's there so far:
>
>- Username password authentication
>- Memory authentication realm
>- Memory group provider
>- Memory role provider
>- Rule based authorization system
>- XML frontend for memory realms
>- XML frontend for group providers
>- XML frontend for role providers
>- Pluggable XML frontend for policies
>- Read-only JDBC realm backend
>
>The interesting stuff here is the pluggable authentication mechanism and the
>rule-based authorization policy mechanism. One of the next objective is to
>demonstrate the power of the rule based approach for policy definition by
>supporting rule definitions in Groovy.
>  
>
Groovy! Sounds like you're playing with all the fun stuff :).

>Of course, APIs are by no means frozen yet, and are subject to change if
>necessary. But I guess the general mechanism won't change a lot. Let me try
>to explain:
>
>The idea is that we go through 4 steps to provide a proper security model:
>
>1. Authentication, where a subject is identified and authenticated through
>pluggable authentication methods
>2. Gathering, where the subject is populated with Principal attributes that
>provide information to the authorization rules
>3. Authorization, where security rules are applied when a subject requests a
>permission to do an operation on a resource)
>In parallel, operations that occur during the process generates events that
>are processed for Auditing 
>

>(EventBus will be a nice fit here).
>
>  
>
Yes it would.

>Currently, there'a almost no docs available (no javadoc, no nothing) but
>tests provide a good insight of how things work if you're interested. Along
>with the groovy engine, the objective of the next release is to provide an
>example application. I am thinking of a small webapp using picocontainer and
>dynaop (or my own proxy library).
>
>If I can make it (which I doubt due to christmas coming) I'd like that
>example webapp to make the first release. We'll see ...
>
>  
>
Cool! Can't wait.

>After that, I'd like to look at some of Eve requirements in terms of
>security (Alex?) to see if Janus can do the job and what's needed.
>  
>
I would like to see if we can use your rule API as the API within Eve to 
determine if certain directory operations are authorized.   The rules 
can be stored within Eve's system backend (ou=system) and use the Eve 
JNDI provider.  Nice thing about this approach is we can make the 
implementation work whether it is code executed inside Eve or outside 
using the JNDI LDAP provider from SUN.

Some of the things however that I'm trying to figure out is how to 
implement things called Authoritative Areas which hold administrative 
information regarding schema and in addition athorization information.  
We basically need to implement RFC 3672 in Eve and use something called 
a subtree specification to select the set of access controls effective 
for an operation.  That combined with your rule language should be what 
we're looking for.  RFC 3672 is on the top of my list along with RFC 3384.

Alex





Mime
View raw message