Hi again,
I don't really know if this is of interest to anyone but me, say so and
I will stop reporting...
anyway, I could not resist the temptation to test this concept (with a
lot of hardcoded stuff)
- A UserCentralService modelled after the JaasSecurityManagerService,
which binds in my current DirContext impl (should be done in some way
similar to LoginModule).
- An extention to the LdapLoginModule wich stuff an LdapPrincipal into
the Subject, with the full dn of the use (decided by the
LdapMoginModule properties).
- An extra method to the AbstractWebContainer (linkUserCentral).
For a security domain (say sec1), the following will be created:
java:user/sec1 (implicit the way the Jaas stuf works today)
java:comp/user (pointing to user data - a DirContext - for the currently
authenticated subject.)
Logged in as pra, with this in the servlet:
DirContext c = (DirContext)ctx.lookup("java:comp/env/user");
if (c!=null) {
System.out.println("Current user data latest: " + c.toString());
}
Would print out:
[Default] Current user data latest: <?xml version="1.0"?>
<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="userPassword"><value>mypass</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>
Yes, you could also use the normal javax.naming.directory api. And if
the context received contains subcontexts, you should be able to get at
them too. And yes, this is only the most bare bone skeleton for what
needs to be supported.
I will definitly go for this in my own enviroment and the products we
produce. If I have to, I will patch the JBoss distributions we use to be
able to have this feature, but it would be nicer to have it there by
default ;-)
By the way: would it not be nice to be able to plug in listeners in the
deployment process to be able to add app specific stuff in the process.
Or perhaps even better follow the same decorator pattern as in the JBoss
container (or is it already possible to do this through JMX based
listeners?).
//Peter
On 19 Okt, Till: [EMAIL PROTECTED] wrote:
> 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.
>>
>> 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).
>
> Hi, I been looking some more into your security stuff, and I have to say
> it rocks, especially the magic you do with the
> SecurityDomainObjectFactory thingy.
>
> I was also reading the JNDI tutorial again and sort of found this in a
> discussion in Naming Policys:
>
> "At the root context of the namespace is a binding with the name
> "comp", which is bound to a subtree reserved for component-related bindings. The
> name "comp" is short for component. There are no other bindings at
> the root context. However, the root context is reserved for the future expansion of
> the policy, specifically for naming resources that are tied not to the
> component itself but to other types of entities such as users or departments. For
> example, future policies might allow you to name users and
> organizations/departments by using names such as "java:user/alice" and
> "java:org/engineering". "
>
> Would not that be an interesting way to go? This could just be an
> exansion of (or inspired by) the stuff you have already done.
>
> - Have a central store for configuration pertaining to a security
> domain, also containing the way you lookup user data. Could be an
> expansion of your SecurityPolicyParser or a new impl of a
> IAppPolicyStore.
>
> - Set up also JNDI for user, some possible examples would be:
>
> java:comp/env/security/user
> java:comp/env/user
> java:user/activeUser
>
> - Use only available Java concept to represent a user and profiles at
> the lowest level (much like you used Subject, Principal and Group),
> which would be a DirContext.
>
> - A DirContext might (as we already know) be tied to different directory
> products. We might even provide a sample one for a RDBM based user
> data store.
>
> It would probably be possible to do some interesting stuff here, for
> example:
>
>
> Attribute dn = (Attribute)ctx.lookup("java:comp/env/user/dn");
> Attribute cn = (Attribute)ctx.lookup("java:comp/env/user/cn");
>
> (I know this is not pure JNDI any longer, but I was so inspired by your
> subject magic, and I already use the Proxy stuff to do DirContext in the
> stuff I am currently implementing.)
>
> // Custom object saved
> MyProfile profile =
> (MyProfile)ctx.lookup("java:comp/env/user/myprofile);
>
> Attribute dn = (Attribute)ctx.lookup("java:comp/user/pra/dn");
>
> DirContext users = (DirContext)ctx.lookup("java:users"):
>
> // Search users on the users DirContext
>
>
> Well, just some thoughts. Any merits in it?
>
> //Peter
>
>
>>
>> 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.
>>
>> Now, adding an LdapContext JNDI provider to JBoss is interesting in of
>> itself. It
>> doesn't need a user management problem to drive 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
