I have confirmed this is still an issue - but it seems to me the correct place
to fix it is in org.jboss.web.tomcat.security.SecurityAssociationValve or
org.jboss.web.tomcat.security.JBossSecurityManagerRealm. The Valve assumes that
if a UserPrincipal is set it will be JBossGeneralPrincipal. What happens if it
is not? If some external process has set up another Principal here we are in
trouble - even if JAAS principles are set up subsequently.
The following will throw a CastException:
if (caller == null || (caller instanceof JBossGenericPrincipal) ==
false)
{
// Look to the session for the active caller security context
if (session != null)
{
principal =
(JBossGenericPrincipal) session.getPrincipal();
}
}
else
{
// Use the request principal as the caller identity
principal = (JBossGenericPrincipal) caller;
}
The problem here of course is that we are assuming that JBOSS will drive the
authentication - couldn't it be possible to make this selectable and reverse
the causation if necessary.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909034#3909034
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3909034
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
