Chris,
On 12/26/2023 11:35 AM, Christopher Schultz wrote:
Jerry,
On 12/24/23 19:18, Jerry Malcolm wrote:
Chris,
On 11/8/2023 2:43 PM, Christopher Schultz wrote:
Jerry,
On 11/6/23 23:22, Jerry Malcolm wrote:
On 11/5/2023 11:54 AM, Jerry Malcolm wrote:
On 11/5/2023 9:26 AM, Christopher Schultz wrote:
Jerry,
On 11/4/23 20:17, Jerry Malcolm wrote:
My support team needs to be able to log in to our site as
various users (on behalf of...) to be able to see exactly what
they are seeing since roles, access groups, history is different
for different users. I would like to implement an admin password
where I can log in as any userId with this password. I totally
realize the security risks involved in this. But I am handling
the security risks with additional authorizations. I simply
need to make every user have two passwords... their real
personal password, and the admin password. The only alternative
I have right now is to save off the user's password hash in the
USERS table, replace it with my password hash, then restore the
user's original password when I'm done. I'm not thrilled with
that solution first because it's a pain and error prone, and
also because the user can no longer log in while their password
is replaced with my password.
I figure this function is buried in the authenticator code
somewhere. But I'd first like to see if anybody has done
anything like this already. If not, could somebody point me in
the right direction to the tomcat source file that I'm going to
need to modify and also what's involved in making authentication
use my updated class instead of the default.
Suggestions?
This sounds like "impersonation" to me, which, I think, can be
done differently. If you are indeed describing an X-Y problem
above, then might I suggest the following?
Instead of figuring out how to "add" a second password to a user,
what about allowing you to login as e.g. "jerry" and then assume
the identity of the user "tom"? You should be able to do this by
changing the UserPrincipal in the session to have a different
username.
Which application are you trying to do this with? Your own
application, or one which ships with Tomcat (e.g. Manager)?
-chris
Hi Chris, it's my own webapp. Changing user principal is exactly
what I'm trying to do. I wasn't aware that the user principal
could be easily swapped. Where can I learn more about how to do
that?
Chris, I'm not having any luck googling info on how to replace the
user principal object in the session object. This is exactly what I
need to do. But looks like I'm going to need a little bit of
guidance to figure out how to implement it.
I forgot that "we" are using our own custom principal and actually
not using Tomcat's authentication and authorization. So we do things
differently.
If you are using FORM authentication, then I think this is a little
easier.
You may have to do a nasty bit of casting to internal Tomcat classes
and/or use reflection, but you can simply call:
org.apache.catalina.Session.setPrincipal(java.security.Principal)
The StandardSession class you probably are already getting from
Tomcat implements that interface, so you should be able to call that.
I think while Tomcat will accept any java.security.Principal, in
practice, you'll want to use
org.apache.catalina.realm.GenericPrincipal.
-chris
I finally had a minute to try to implement your suggestion from a few
weeks ago. I got everything coded. But I'm getting a
ClassCastException when trying to retrieve StandardSession. I'm
getting a StandardSessionFacade object instead of StandardSession. I
looked at the javaDoc hoping to find a way to get the StandardSession
from the facade object. But no luck. Am I not going about this
correctly in my code? How can get access to the StandardSession
object instead of the StandardSessionFacade object? Thx
GenericPrincipal newPrincipal = new GenericPrincipal(
getUserName(), getPassword(), roles );
((StandardSession)getCtrl().getRequest().getSession()).setPrincipal(
newPrincipal );
Hmm. It seems that StandardSessionFacade is used to prevent the kind
of thing you are trying to do, probably as a protection against
potentially malicious applications.
If you are willing to get messier, you can use reflection to get the
value of the StandardSessionFacade.session member, which will be a
StandardSession object.
Another option is to do what my application does, which is to store
the user in a session attribute and then wrap each request in a Filter
making it available:
doFilter(...) {
HttpSession s = request.getSession(false);
if(null != s) {
final User u = s.getAttribute("user");
if(null != u) {
// Wrap request
request = new HttpServletRequestWrapper(request) {
public Principal getUserPrincipal() {
return u;
}
};
}
}
chain.doFilter(request, response);
}
The above is psuedocode typed from memory. I'm fairly sure we create a
new Principal object because our User object doesn't actually
implement Principal.
-chris
I implemented the filter as you suggested. But I guess I'm going to
need some education on sessions. Down in a user profile web page I have
a button to "Impersonate". I create the GenericPrincipal object and
store it in the session. I've checked several times, and every time I
come back to that code, the attribute is set in the session object. But
when I put breakpoint in my new Filter object and look in the session,
no attribute. It's a different session object from what I can tell. I
really thought I understood session objects. I thought there was only
one session object throughout the processing of a servlet. But I'm
obviously missing something in the flows. Why is there a different
session object in the filter than in the main body of the servlet? I
did the getSession(false) as you suggested. The session object is not
null. It just doesn't have the attribute set. Yet if I hit the
Impersonate button again and hit the breakpoint, the GenericPrincipal
attribute is sitting in the session just as I placed it earlier.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
