Accessing j_username j_password with Catalina

[johnnycannuk]

I have a portion of code in my servlet that accesses the j_username and j_password session variables so I can log into the database.

On jboss2.4.3_Tomcat-3.2.3 I call

request.getSession(true).getAttribute("j_username");
request.getSession(true).getAttribute("j_password");

and get:
scott
echoman

The identical code on jboss2.4.4_Tomcat4.0.1-beta returns :

null
null

I am able to use my beans ok as before, but if I need to have the user log into a database as themselves (and use single sign-on) I now cannot access this information.

Am I missing something?

Mike

[luke_t]

You shouldn't be accessing username and password in this way. It is just coincidence that Tomcat 3 stores them this way in the session and there is on guarantee that this will be portable - in fact as you've seen it isn't. The names j_username and j_password are only there to provide portable form-based login among different servlet containers. They are never supposed to be directly accessed by your code.

[johnnycannuk]

Point taken...I though there may have been security issues with accessing them in 3.2.3.

So then, does anyone have any way of accessing these security principals in code (in a session bean, for instance) so a user may log into the database as themseleves and use JAAS as a "single sign on" protocol for the app? I suppose we could just create "shadow" session variables, but I'd prefer the cleaner approach of getting the information from the Subject and it's Principals.

We need a user to be able to sign on as say scott/ echoman and then have any ejb's the user uses connect to the DB as scott/echoman as well instead of a priviledged user (the same username/pw combo from the connection pool). This just adds an added level of security.

Mike

[luke_t]

Sounds like this might be pretty inefficient if you have a lot of traffic.

There are potentially quite a lot of issues here...

You *can* obtain information from the Subject, but what is in there depends on the login module you use. By default JBoss stores the principal and roles in the list of subject principals. You can provide your own modified login module which will add other information to the list of private credentials stored.

Are you using the database to store security information (e.g. using DatabaseServerLoginModule)? If so, then this will presumably be readable using a normal datasource and unless you modify it to store hashes (for example) then the login/DB credentials for all your users will be readable anyway.

Why do you think you need the "added level of security"? i.e. what threats do you foresee that justify having to login to both jboss and the DB separately.

Do you have information that is private to each user? If so it might be worth thinking about using encryption to protect this rather than relying on the database security.