I'm interested but the scope of this discussion is too limited and the
exposure
of the password to the application level should not be done. The desire to
authenticate against an LDAP server as the current user is a need that
exists
everywhere:
- Propagate the caller authentication for nested EJB calls.
- Access a DataSource connection as the current caller
- Access a filesystem resource as the current caller
- Obtain a JMS connection as the current caller
- Perform a JNDI lookup as the current caller
...
Single-sign on and propagation of the current caller needs to be handled
generically
at the server level using some construct that is compatible with the JCA
architecture
so that all resources may be secured without the application code dictating
access
to the user authentication credentials. The only time the credentials should
be exposed
to the application is if the component in question has declared a res-auth
tag with a
value of 'Application'. In this scenario access to the user credentials
should not be
a link from the component ENC, but a binding that only the component has
access
to. If the component then chooses to expose the credentials to a wider scope
that is
its prerogative.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "Peter Antman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 6:43 AM
Subject: Re: [JBoss-dev] User API; was Tomcat security/LdapLoginModule
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
