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
