Now on to the problem. Basically, I have a client application that runs a bunch of applets. Our application, at start up, creates a Authenticator and sets it as default. When we first try to get a session from the server (running on Weblogic), which is all done through servlets, we get the little username/password as expected.
The problem is the users have decided they want the ability for an application adminstrator to be able to log in within the same session (so different credentials than logged in previously) and do some administrative stuff, like release a locked resource.
So the flow would be User A (non-administrator) opens the application, realizes something is hosed with a resource, and asks User B (administrator) to release it. User B clicks on an Administrator Release button, which creates a new Authenticator, sets the current default to null (which according to the API should remove any current authenticator) and then sets the default to the new one. A session is then created which when requested should ask the new user for their username and password. That's then validated and checked for admin rights, and the resource is released. We reset back to the previous authenticator, and User A can then go about their work.
I would expect to have the new Authenticator's request for username and password be shown, however it appears to be using the previous credentials, even when I null out the default authenticator without resetting the default.
Oh yeah, this is all on SDK 1.4.1_13. Yay for being behind the times!
I would love to post code snippets, but das ist verboten where I work.
And hopefully this makes sense.
Thanks for any help, peace! Jason [ July 07, 2008: Message edited by: jason adam ]
I am not really sure i got the stuff related to authenticator. When you say session i assume you are talking about an HTTPSession, isnt?
So, one question, if you update the HTTPSession and add admin privilege, then i assume the other user will also be able to browse through and use admin privileges, isnt? Will this not be a security breach?
The problem is the users have decided they want the ability for an application adminstrator to be able to log in within the same session
I would think that the requirement is to "see" the other user's session and not "use" the same session. I think using the same session will not be a correct way of doing things as HTTPSessions are not really supposed to be used like that. I would approach it in this way:
Store the HTTP session in a class that can provide access to the session contents. (Clear this using a session listener)
Give admin the privilege to see/alter any one's session.
If resources can be modified/released only in the same session they were created, then modify them to allow admins to change them from any session.
It sounds as if you're using BASIC authentication. Once a user has entered username/password into that, browsers will send it to the server with each request until they're closed. In that sense, there's no concept of "logging out". (Which, incidentally, is one of the reasons I've completely stopped using container-managed servlet security.)
You could set up a different realm (i.e., a realm with a different name). That would cause the browser to ask the user for the new credentials. But again, that would be sent as long as the browser is running - no "logging out" of the admin realm. Then both usernames/passwords would be sent with each request all the time.
Ping & DNS - updated with new look and Ping home screen widget