On 17 Okt, Scott M Stark wrote:
> We do need a centralized notion of user, authentication and authorization
> and profiles. Our current fragmented notion does not make any sense
> administratively.
Nod.
>
> Basically we want a single API and administrative interface for the
> following
> 1. Who is the user and what is their proof (authentication).
> 2. Is the user authorized for the current action (authorization).
> 3. What properties does the authenticated user have in a given context
> (profiles).
>
> Associating the store of this information with an LdapContext JNDI provider
> seems
> an unecessarily opaque abstraction. That the information can be obtained
> from
> JNDI should be an implementation detail.
Well, I both agree and do not agree. Maybe you have a much longer
experience with handling user data and the problem of exposing a user
data API. I have been fighting with it on and of for the last 2 years
without recognizing a really good solution: JBoss is not the only
project that suffers from fragmentation when it commes to the abstract
notion of a user.
Currently I work with the hypothesis that LDAP is actually a possible
solution to this fragmentation/user API problem. LDAP has a well defined
notion of an entry and what it might contain, the schemas are well
elaborated (and extensable) and it has a well understood notion of how
to name stuff in a unique way.
Using LDAP also have the following advantages (especially in the context
where we would have a simple native "LDAP server").
- Easy to migrate to an enterprise setting (set up OpenLdap or some of
the other LDAP server available and change the LDAP URL).
- Easy for non java/non J2EE applikations to also access user data.
- Third party tools available.
There are pitfalls to, yes. What if someone already have a well defined
database schema used for all their users. Here we have a problem.
- Either cases of this sort would not be able to "participate" in the
unifyed user handling.
- Or an adaptor pattern would have to be used.
The adaptor stuff could be used at several levels.
1. We could have a LDAP inspired API at the top, with different
backends (much like we today have different LoginModules) but with
the requirement that the user/entity and its profiles is exposed in a
unifyed maner.
2. The JNDI stuff I am working on is based on the decorator pattern
(much like the JBoss container) and different decorators for
different naming domains could be developed/deployed.
3. I guess you could also use some cind of JNDI mechanism to delegate
calls to an underlying database engine to fetch the info (I have not
tested this yet).
(The crux here is ofcourse how to map (JNDI directory/LDAP) filter
querys to other cind of query mechanisms - as Xpath or SQL - my current
hypothesis is that it would be fairly easy to translate these filter
into an XML representation and then do the transformation with XSL-T).
I do think that the Subject/Principal/Group/Credentials is a great way
of abstracting the user entity for autentication and autorization and
for further lookup. And I do think that LDAP has some merits when it
commes to defining the interface for profile information.
Apart from beeing able to actually use DSML XML as the autoritive way of
exposing user data, I think it would be possible to build a set of
interfaces that is "inspired" from the currently available LDAP schemas,
and use the Proxy stuff to make these interfaces available.
interface Entry;
interface Person extends Entry;
interface InetOrgPerson extends OrganizationalPerson;
interface GroupOfUniqueNames;
A common InvocationHandler could be developed that can handle get and
even set stuff.
An EntryLdapFactory for example could do this:
Entry getEntry(DirContext) {
EntityInvocationHandler h = new EntityInvocationHandler();
// Fill it with LDAP data
Class[] interfaces = null;
// Get all interfaces to implement
return (Entry)
Proxy.newProxyInstance(Thread.currentThread().
getContextClassLoader (),
interfaces,
h);
}
With enough abstractions something like this could be done in user
space:
UserCentral uc = UserCentral.getInstance();//Would be centraly configured
//Would use jndi to get the subject, or perhaps this should
// be done in user space
Entry entry = uc.getCurrentSubjectEntry();
if (entry instanceof InetOrgPerson) {
IntOrgPerson p (InetOrgPerson)entry;
String homePhone = (String)p.getHomePhone();
//...
}
>
> Now, adding an LdapContext JNDI provider to JBoss is interesting in of
> itself. It
> doesn't need a user management problem to drive it.
It's a DirContext provider because it does not have any LdapControls,
and it is currently based on the com.sun.jndi.toolkit.dir.HierMemDirCtx
class. It is also verry basic at the moment.
If we in any way should include this in JBoss, where would we place it?
In an own module, try to extends jnp instead, contrib?
//Peter
Ok, I know this bacame a longish mail. But here is the current quick
start of what I am developing internally. Mostly for you to get a chance
to see if it would be of any interest.
Quick Start UserCentral JNDI
============================
Peter Antman 12/10 2001
UserCentral contains a XML:ish JNDI implementation. It support two cind
of nifty features:
- Run it as a frontend (facade) for any JNDI directory provider (preferably LDAP) and
you can serialize contexts and NamingEnumerations to DSML XML, much like the SUN ea
DSML JNDI provider (but much better ;-) ( see www.dsml.org)
- Use the embedded XML/LDAP backend for easy boostrapping of user handling. With it
you can store your directory data in a local XML file, but access it through the
fullblown JNDI directory API.
UserCentral JNDI is build according to the decorator pattern (GOF) and may decorate
incomming and outgoing calls to any DirContext JNDI provider. It has built in support
for decorating some of the objects as DSML XML when toString() is used.
XMLing a standard JNDI DirContext provider.
-------------------------------------------
The DSML support in UserCentral has the following features:
* Work agains the provider as normal, both read and write are supported. Changes made
agains the fasade is also made to the backend (as opposed to SUN DSML flawed
behaviour).
* Serialize objects as DSML XML. Currently only works for real entries and not
for scheamas. Does currently not support namespaces in the generated XML.
- Setup -
The setup is done through the environment by adding the decorators (interceptors) to
the se.tim.jndi.chained.classes variable. You also have to specify the UserCentral
InitialContextFactory as your JNDI factory and put the real provider factory in the
variable se.tim.jndi.factory.initial.
For SUN LDAP this might look like this:
Hashtable env = new Hashtable(11);
// Put the ChainedCtxFactory as the factory
env.put(Context.INITIAL_CONTEXT_FACTORY,
"se.tim.jndi.ChainedCtxFactory");
// Put in the real provider
env.put(se.tim.jndi.ChainedCtxFactory.FINAL_INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
// Specify DSML decorator
env.put(se.tim.jndi.ChainedCtxFactory.CHAINED_CLASSES,
"se.tim.jndi.dsml.DSMLInterceptor");
// Set up the normal LDAP stuff
env.put(Context.PROVIDER_URL, "ldap://localhost/dc=tim,dc=se";);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL,"cn=manager,dc=tim,dc=se");
env.put(Context.SECURITY_CREDENTIALS, "gueswhat");
You may then work against this as against any normal JNDI provider.
If you want to work with your directory data as XML use toString() on any
context or NamingEnumeration (and any contained NameClassPair or SearchResult).
The DSML decorator does not do a deep search. You will only get entries that
are directly under your current context (as oposed to SUN DSML)
For examle, say you lookup an entry
DirContext ctx = new InitialDirContext(env);
ctx.lookup("uid=pra,dc=tim,dc=se").toString();
Might result in the following XML:
<dsml xmlns="http://www.dsml.org/DSML";>
<directory-entries>
<entry dn="uid=pra,dc=tim,dc=se">
<objectclass>
<oc-value>top</oc-value>
<oc-value>person</oc-value>
</objectclass>
<attr name="mail">
<value>[EMAIL PROTECTED]</value>
</attr>
<attr name="uid">
<value>pra</value>
</attr>
<attr name="givenname">
<value>Antman</value>
</attr>
<attr name="sn">
<value>Antman</value>
</attr>
<attr name="cn">
<value>Peter Antman</value>
</attr>
</entry>
</directory-entries>
</dsml>
Listing a context might result in like this:
ctx.list("dc=tim,dc=se").toString();
Might give you this:
<?xml version="1.0"?>
<dsml xmlns="http://www.dsml.org/DSML";>
<directory-entries>
<entry dn="uid=mf,dc=tim,dc=se">
<objectclass>
<oc-value>top</oc-value>
<oc-value>person</oc-value>
</objectclass>
<attr name="mail">
<value>[EMAIL PROTECTED]</value>
</attr>
<attr name="uid">
<value>mf</value>
</attr>
<attr name="givenname">
<value>Magnus</value>
</attr>
<attr name="sn">
<value>Fredlund</value>
</attr>
<attr name="cn">
<value>Magnus Fredlund</value>
</attr>
</entry>
<entry dn="uid=pra,dc=tim,dc=se">
<objectclass>
<oc-value>top</oc-value>
<oc-value>person</oc-value>
</objectclass>
<attr name="mail">
<value>[EMAIL PROTECTED]</value>
</attr>
<attr name="uid">
<value>pra</value>
</attr>
<attr name="givenname">
<value>Antman</value>
</attr>
<attr name="sn">
<value>Antman</value>
</attr>
<attr name="cn">
<value>Peter Antman</value>
</attr>
</entry>
</directory-entries>
</dsml>
Working with the local XML storage
----------------------------------
UserCentral also commes with its own LDAP JNDI provider. This provider has (currently)
the following features:
- Represents all entries in Memory.
- Persists to an XML store
- Pluggable persistence managers (FilePM is implemented)
- Supports plain LDAP entries.
- No schema support, no object binding, no URL or federation (will comme).
The only driver currently implemented is a file driver. This reads from a file
and persists each change by regenerating the whole file. It's nice to use for a
smaller number of entries. An EJB driver will be developed.
You set up the provider by using properties as is normal with JNDI. Here are a
commented setup.
Hashtable env = new Hashtable(11);
// Use the facade
env.put(Context.INITIAL_CONTEXT_FACTORY,
"se.tim.jndi.ChainedCtxFactory");
// put se.tim.jndi.dsml.DSMLCtxSingletonFactory as the real provider
env.put(se.tim.jndi.ChainedCtxFactory.FINAL_INITIAL_CONTEXT_FACTORY,
"se.tim.jndi.dsml.DSMLCtxSingletonFactory");
// Specify the persistence manager for DSMLCtx to use
env.put(se.tim.jndi.dsml.PersistenceManager.PERSISTENCE_MANAGER,"se.tim.jndi.dsml.FilePM");
// Put the DSML decorator in ( to be able to serialize XML)
env.put(se.tim.jndi.ChainedCtxFactory.CHAINED_CLASSES,
"se.tim.jndi.dsml.DSMLInterceptor");
// Configure the provider. Point an XML file out, must be in DSML format
// without any namespace stuff.
env.put(Context.PROVIDER_URL,
"file:/home/pra/src/UserCentral/src/se/tim/uc/scratch/dsml/test3.xml");
// It is also possible to specify a default domain which is not part of the
// actual tree or entries (as in a standard LDAP server):
//env.put(Context.PROVIDER_URL,
"file:/home/pra/src/UserCentral/src/se/tim/uc/scratch/dsml/test3.xml?dc=tim,dc=se");
// Get the context
DirContext ctx = new InitialDirContext(env);
You will now have access to all the users and groups found in the XML file througn the
standard JNDI API. Any changes (adding, changing, removing) will be persisted to the
XML file.
As with a standard provider used through UserCentral JNDI it is also possible to
serialize stuff to DSML XML.
Cool, ain't it?
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> ----- Original Message -----
> From: "Peter Antman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 17, 2001 7:42 AM
> Subject: [JBoss-dev] Tomcat security/LdapLoginModule
>
>
>>
>>
>> (I could perhaps also take the chance to ask about any interest to
>> incorporate another cind of user handling into JBoss core. The last week
>> I have been implementing a simple JNDI directory LDAP provider. The
>> story for the time beeing is that it is an in memory LDAP
>> server/provider which is also backed by a persistence manager, currently
>> only a FilePM is implemented. The user data is saved as DSML (see
>> www.dsml.org) XML, wich mean you may edit it by hand, or change it
>> though the normal JNDI interface.
>>
>> I do admit that the file based persistence is probably really slow once
>> you get some users into it, but it is possible to write a better
>> persistence manager, and better yet, when it grows you can just
>> reconfigure to make the stuff run against a real Ldap server, much like
>> DefaultDS works today.
>>
>> OK, question is basically this. Would there be any interest in
>> incorporating this into JBoss to make it handle users - perhaps even
>> JBossMQ users. If we did this it would be plain easy to write a little
>> management web gui to administer users/roles in JBoss.
>>
>> Another cool feature with this stuff is that it also works much like the
>> sun DSML JNDI provider, but with real persistence. I.e, doing a
>> dirContext.toString() or namingEnumeration.toString() will get you a
>> DSML XML representation of your directory entry(s).
>>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
