Probably you can define interface and use casting while you are accessing your Principle implementation. Frankly, I didn’t try it but it seems like usable solution.
There is another technique that is quarantined to work though. It is very simple and employs only Java’s Reflection. Four days ago I send an e-mail to [EMAIL PROTECTED] explaining how Reflection may be used to extract user’s password from org.apache.catalina.realm.GenericPrincipal and so fare I didn’t get any response. Probably this is not treated as security issue so let me make it public. Attached you will find my original e-mail to [EMAIL PROTECTED] explaining how this may be accomplished and how one can protect himself from such exposure. Regards, Rossen Raykov > -----Original Message----- > From: John H [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 15, 2004 1:32 PM > To: Tomcat Users List > Subject: Re: Extending GenericPrincipal/RealmBase: > Essentially a classloader question > > > Webapps can see GenericPrincipal only when I move > catalina.jar to common/lib. That's the kicker. Catalina has > supplied a nice generic principal that implements > java.security.Principal in useful ways, but then prevents me > from using it in my webapps (directly or through extensions). > > I must be missing the reasoning behind that. > > ----- Original Message ----- > From: "Benjamin Armintor" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > Sent: Thursday, April 15, 2004 12:34 PM > Subject: RE: Extending GenericPrincipal/RealmBase: > Essentially a classloader question > > > Can your webapps see GenericPrincipal? Looking at the > JavaDocs for the Catalina api, it looks like the session > façade your get app gets is going to have access to a > java.security.Principal (likely also a façade), not a > GenericPrincipal. Maybe instead of extending a class in the > server/Catalina classloader, you could implement another > subclass of java.security.Principal, and have that class > loaded in the common classloader. > > Benjamin J. Armintor > Systems Analyst > ITS-Systems: Mainframe Group > University of Texas - Austin > tele: (512) 232-6562 > email: [EMAIL PROTECTED] > > > > -----Original Message----- > From: John H [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 15, 2004 11:25 AM > To: Tomcat Users List > Subject: Extending GenericPrincipal/RealmBase: Essentially a > classloader question > > > HI all, > > He have implemented our own realm and principal buy extending > org.apache.catalina.realm.RealmBase and GenericPrincipal. > > (Using TC5.0.19 on Solaris and Windows. Realm defined in <Context>.) > > By doing this, however, we've got ourselves into sort of a > catch 22 in terms of classloading. Hopefully someone can > offer some assistance. > > I've referenced the Class Loader HOW-TO at > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-h owto.html, so I'll use it's terminology. RealmBase and GenericPrincipal are located in catalina.jar, which resides physically in server/lib. The howo defines this jar as in the Catalina class loader. The definition says that the Catalina classes are totally invisible to web applications, which seems true enough. In order to extend these, I must locate my jar in server/lib. So far so good. The problem is that I need to use my extension of GenericPrincipal within my webapps. I tried moving my jar to common/lib, since, according to the parent tree in the howto, it is visible to both the Catalina branch and the webapp branch. Doing this causes a NoClassDefFoundError for GenericPrincipal. Apparently since the Catalina classloader is below the common classloader, it can't find GenericPrincipal. The only solution that appears to work is moving the entire contents of server/lib to common/lib, essentially 'promoting' all of the classes normally in the Catalina class loader to the common class loader. Is this the best solution? It seems to me that I should be able to extend RealmBase/GenericPrincipal without having to move jars around. Any ideas? John --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--- Begin Message --- Title: Principal's password exposureTomcat's implementation of java.security.Principal
org.apache.catalina.realm.GenericPrincipal is exposing user's password to
the applications.Class info:
GenericPrincipal is having method declared as:
<code>
public String getPassword()
</code>
which returns principal's password.
This method is used by the various realm implementations in the same
package.Problem description:
Although GenericPrincipal is instantiated by a different class loader an
application may use Java's reflection to obtain principal's password.
This problem exists in both 4.x and 5.x implementations and probably in all
earlier versions.Example:
<code>
Principal p = request.getUserPrincipal();
Method m = p.getClass().getMethod("getPassword", new Class[] {});
String pwd = (String) m.invoke(p, new Object [] {} );
</code>Proposed solution:
The method descriptor should not be declared as public.
Leaving it with default visibility will prevent this problem from happening.
<code>
String getPassword()
</code>Regards,
Rossen Raykov
--- End Message ---
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
