On 17 Okt, Scott M Stark wrote:
> ----- Original Message -----
> From: "Peter Antman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 17, 2001 7:42 AM
> Subject: [JBoss-dev] Tomcat security/LdapLoginModule
>
>
>> Hi (mostly Scott I guess),
>>
>> I have been experimenting with the JAAS security framework and Tomcat
>> lately. It is a really great pice, but I do have some
>> comments/questions.
>>
>> 1. Secured web resources without a jboss-web.xml are not secured.
>>
>> Using a tomcat with JBossSecurityMgrRealm as authenticator makes it a
>> requrement to have a jboss-xml.web with a security-domain. If you deploy
>> a war with only webresources and no jboss-web, security-contraint
>> resources will allways be authenticated since the default behaviour when
>> a security manager is not found by JNDI is to let it through.
>>
>> Would it not be good to have a default security-domain for war:s wich
>> does not have a jboss-web.xml, sort of that we can deploy ejb:s without
>> an jboss desciptor.
> Neither ejbs or web apps can be deployed securely without a JBoss
> descriptor declaring the security-domain so there is no inconsistency here.
> That a deployed war ignores this fact and allows access to secured content
> is based on that a web app can call getUserPrincipal or getRemoteUser and
> receive a null value when there is no security context. Either call results
> in an
> authentication request and this was filling up the log with login failures
> when
> unsecured servlets invoked these calls. In the absence of any
> security-domain
> element a NullSecurityManager is installed for a war that allows all access
> to
> avoid this. A check for secured content could be made by looking at the
> web.xml
> descriptor and in this case install a deny all security manager which is in
> effect
> what occurs with secured ejbs that do not have a valid security-domain.
Ok, I understand this and maybe it a little thing to demand to just fill
in a
<jboss-web>
<security-domain>java:/jaas/nosec</security-domain>
</jboss-web>
At the same time I think that it should be possible to use the
JBoss-Tomcat only as a great webapp deployment container. And since that
combination will result in the Tomcat default behaviour how to handle
users (the in memory realm handler) beeing removed and instead the JBoss
security manager beeing used this means that Tomcat default behaviour is
changed:
- It is impossible to deploy a webap with a security-constraint and
login-config and get tomcat/JBoss to authenticate the user unless you
specify a jboss-web.xml.
I do think a reasonable default would be a security domain "other" that
is configured to work against a default user store: property files or
ldap or whatever, much like Tomcat has a default way of doing in.
I will not press hard on this. I only still think it would be resonable
to have a default user stor (security domain).
>
[..]
>>
> The actvie subject is available through JNDI:
> Subject activeSubject = (Subject)
> ctx.lookup("java:comp/env/security/subject");
>
> for both ejb and web components.
Great, great, great!
>
>> 3. It would also be great if you could specify the Subject to hold on to
>> the credentials (perhaps it is dangerous, but it is also the only way
>> I can figure out how to get at the password - for example if you want
>> to access user info in LDAP and want's to bind as the currently
>> autenticated user.)
>>
> You can put whatever you want into the Subject.getPublicCredentials() Set as
> well as the Subject.getPrivateCredentials() Set. In general you would have
> to setup permissions carefully to only allow access to sensistive
> information in
> the PrivateCredentials Set using a security policy.
>
>> 4. Scott, what do you say about also letting the LdapLoginModule
>> setting a principal in the Subject with the full DN of the
>> autenticated user. Then we could have a more unifyed way of working
>> with an autenticated Ldap user, for example in a servlet:
>>
>> Subject subject =
>> (Subject)req.getSession().getAttribute(JBossJaas.SUBJECT);
>> if (subject != null) {
>> Set p = subject.getPrincipals(LdapDNPrincipal.class);
>> Set c = subject.getPrivateCredentials(LdapPasswd.class);
>>
>> // Extract the dn and credentials and get the entry from JNDI
>>
>> }
>>
>> This could - I guess - be further elaborated into a nice set of classes
>> to work with users both in the web- and ejb-container without having to
>> do to much redundant configuration. But I guess I have also missed a lot
>> of traps here.
>>
>>
> This is too login module specific for me. A more generic mechanism for
> conveying
> detailed information about the authenticated user is needed.
I agree. Only wanted to sort of sketch whats needed. As far as I can see
it, the only way of really unifying this would be to hide it behind some
cind of interface/factory/central. This should be configured centrally
and would therefor know what LoginHandler was used, how it was
configured and what to expect in the Subject.
To use Ldap as an example: Both the LdapLoginModule and some cind of
helper class to get at the Ldap entries should be conntected. This way
the helper class could take a subject, and know what to look for without
exposing this to the end user.
But as you say in another mail, this would have to be part of a more
general user/profile/auth handling.
//Peter
>
>
>
> _______________________________________________
> 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
