My source tell me that these two standard intitiatives will for the basis for J2EE security in the future. Take a look at them and see how that affects your design.
http://www.oasis-open.org/committees/security/ http://www.oasis-open.org/committees/xacml/ As for where to the DirContext naming stuff, just put it in org.jboss.naming. I had plans for updating jnp to support the DirContext so you can start with what you have. For now just keep it seperate from jnp and it can be federated into the current namespace for testing. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Peter Antman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 18, 2001 1:26 AM Subject: Re: [JBoss-dev] Tomcat security/LdapLoginModule > 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? _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
