On 19 Okt, Scott M Stark wrote:
> I'm interested but the scope of this discussion is too limited
Shure, my primary interest just now is on a user API for user profile
(directory data)...
> 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
>
but ofcource you are correct. I was partly blinded by my focus on
website login, and when I wrote about single-sign-on I actually meant
sigle signon between different web sites, much like the MS passport
service.
Obviously we must also have a "single-sign-on" internally in the server
for all different cind of resources one want't to expose to the
client/components. That's actually darn obvious.
Kerberos would be the answer, if we could only trust that every resource
will be able to handle kerberos, which they won't. Following the pattern
from S2ML and SAML the use of a cryptografic mechanism must be
introduced for resources that uses an autenticated subject/entity to be
able to trust the autenticator and to get access to any credentials that
has to flow with the autentication assertion. Systems that is fully SAML
compatible will not need there own credentials from the client (much
like kerberos and the ticket granting ticket), but this will not be true
for RDBMS/fileystem/LDAP/JMS for a long time (I guess).
One possible solution for tight systems (which a container is) is to
integrate the autentication mechanism (JAAS, LoginModule) with the
access points to the resource (JCA,JNDI, LDAP ...). That is, it is up to
each resource adapter/system to handle the propagation of credentials.
The esiest way would actually be that each systems login module encrypt
the credentials and stuff them in the private credentials of the
subject. With good encryption this would make the credentials of that
particular resource opaque to all other parts of the system using the
subject.
As long as they are not all capable of handling something like kerberos,
and (clear text) passwords are still needed I can se no other resonable
aproach. Otherwise you would have to setup a central repository for all
the passwords for the different systems, which would be a nice target
for atacks.
At a first architectual level, this would mean that to be able to
autenticate as the the current user, each such system must have added a
LoginModule to the auth chain for that particular security domain, and
that the LoginModule works in cooperation with the API/adapter giving
access to the resource data, probably by using some sort of
encryption/ticket granting mechanism internally known only the the parts
handling the resource.
This could probably be made pretty generic for JCA stuff (JBoss would
have to handle both the LoginModule and the encrytion/decryption of
credentials. For LDAP it would not be that hard either, I think.
Or is it better to wait for SUN to make a stand on this things (and they
will eventually!)? Should we only implement stuff that is standardized
for the container?
Well, just my 2c.
//Peter
...
>
> 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
--
------------------------------------------------------------
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
