You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by dirk ooms <di...@onesparrow.com> on 2012/05/24 01:01:41 UTC
user switching or application interacting with container based
authentication
Hello,
we are running a web application with form based authentication. we now
have a requirement to switch between users (for subsets of users) with a
minimum of user interaction (log out and log in providing username &
password is way too much work for the user). so i was thinking of
providing each user with a badge with a unique barcode (a hash of
username&password?) which they can scan into a dedicated field in the
webpage and which will trigger the user switch. note that this barcode
field will only be available once a person has logged in in the normal
way (form based), so the user switch request is received within an
authenticated session.
the difficult part of the story is how can i tell the 'container based
authentication' that the current session is transferred to another user
with possibly other roles OR how can i create a new session for the new
user (so applying the correct authorization and providing a
HttpServletRequest returning the correct values of getUserPrincipal()
and isUserInRole()). the application is able to retrieve the user and
its roles, but how can the application inform the container about this.
i've been googling and reading for hours now and i'm a bit lost
(understatement) on how to proceed with this. it could also be the case
that there are much better scenario's than the one i have in mind.
any hint on fast-user-switching or
applications-interacting-with-container-based-authentication are very
welcome.
cheers,
dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
On 5/23/12 7:06 PM, chris derham wrote:
> We had an app where support staff can login, and then on a special
> form enter the username of the person to impersonate and their own
> password (to prevent abuse), and the system then allows them to
> impersonate the user. Worked well for viewing exactly what the user
> was seeing when reporting issues. To do this we used acegi security
> - has built in support for impersonation.
NB: ACEGI is now called "Spring Security".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk++R/gACgkQ9CaO5/Lv0PAgXwCgtJy6H3IQ/zTXXAGE8NTfmYMN
nSEAnjDvGCXJBkvAyP4dTtCNgGq0Bnp/
=xMMQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based authentication
Posted by chris derham <ch...@derham.me.uk>.
>
>
> any hint on fast-user-switching or
> applications-interacting-with-container-based-authentication are very
> welcome.
>
Dirk,
We had an app where support staff can login, and then on a special form
enter the username of the person to impersonate and their own password (to
prevent abuse), and the system then allows them to impersonate the user.
Worked well for viewing exactly what the user was seeing when reporting
issues. To do this we used acegi security - has built in support for
impersonation.
HTH
Chris
Re: user switching or application interacting with container based
authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dirk,
On 5/24/12 4:51 PM, dirk ooms wrote:
> changing a user object in the session is something i already did.
I misspoke: SF stores the /user principal/ in the session. When you
change that, the identity of the current user (roles and all) changes.
Note that this is *not* container-managed security.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk++21oACgkQ9CaO5/Lv0PAd7ACff4eeBaBZVryXqmG3/Shj62hJ
/hIAn3thz6husf/WnbJ4HYwCxNW+J82J
=mWc5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by dirk ooms <di...@onesparrow.com>.
> >
>
> How about your barcode (or card or whatever) idea, to allow users to switch id on-the-fly
> ? I am curious as to how you implement that.
after some user has logged in in a 'normal/standard' way (using e.g.
form-based, container-managed), there is a text input field in the
header of the secured web page. if another user scans his personal
barcode which could be e.g. a hash of his username and his hashed
password into this field, there will be a switch to this new user (just
by setting its 'user object' in the session). to validate this hash, the
application just loops over the limited number of users of that specific
(small) company to find a match. the container is no longer involved in
authorization, the existing session is reused by the new user. this
method has the advantage that one can only switch between users of the
same 'company/shop' and that someone of that company must have logged in
in a standard way before any user switching becomes possible.
dirk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by André Warnier <aw...@ice-sa.com>.
dirk ooms wrote:
> Chris, Andre,
>
> thanks for sharing your thoughts, it helped me to see things more clear.
>
> changing a user object in the session is something i already did. the
> problem with this was (and which was triggering my initial question) is
> that a new user could have access rights to more functionality than the
> first user, but that the access to this functionality is blocked by the
> container because of the role based security constraints i have defined
> in web.xml (the container does not know that there is a new user with
> other roles, so it still applying the access rules of the first user).
>
> anyway to move forward i decided to use the container-managed
> authentication just as yes/no to obtain access to the complete
> application and to move authorization to the application itself.
>
How about your barcode (or card or whatever) idea, to allow users to switch id on-the-fly
? I am curious as to how you implement that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by dirk ooms <di...@onesparrow.com>.
Chris, Andre,
thanks for sharing your thoughts, it helped me to see things more clear.
changing a user object in the session is something i already did. the
problem with this was (and which was triggering my initial question) is
that a new user could have access rights to more functionality than the
first user, but that the access to this functionality is blocked by the
container because of the role based security constraints i have defined
in web.xml (the container does not know that there is a new user with
other roles, so it still applying the access rules of the first user).
anyway to move forward i decided to use the container-managed
authentication just as yes/no to obtain access to the complete
application and to move authorization to the application itself.
thanks,
dirk
On Thu, 2012-05-24 at 10:37 -0400, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dirk,
>
> On 5/23/12 7:01 PM, dirk ooms wrote:
> > any hint on fast-user-switching or
> > applications-interacting-with-container-based-authentication are
> > very welcome.
>
> We use securityfilter for AAA and the user is stored in the session:
> you can just replace the user object and boom: you are a new user. We
> support "user impersonation" in this way and allows administrators to
> masquerade as another user and then go back to their original login.
>
> Switching to securityfilter may not be a great plan for you, though
> it's not terribly hard to do. But, its a possibility.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk++R7gACgkQ9CaO5/Lv0PBVSQCePHZUW/l2Ybdcqegu206zfY+g
> 6rIAniyLbfpW0m96AeietxvHYXysOW7r
> =ROLF
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dirk,
On 5/23/12 7:01 PM, dirk ooms wrote:
> any hint on fast-user-switching or
> applications-interacting-with-container-based-authentication are
> very welcome.
We use securityfilter for AAA and the user is stored in the session:
you can just replace the user object and boom: you are a new user. We
support "user impersonation" in this way and allows administrators to
masquerade as another user and then go back to their original login.
Switching to securityfilter may not be a great plan for you, though
it's not terribly hard to do. But, its a possibility.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk++R7gACgkQ9CaO5/Lv0PBVSQCePHZUW/l2Ybdcqegu206zfY+g
6rIAniyLbfpW0m96AeietxvHYXysOW7r
=ROLF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by André Warnier <aw...@ice-sa.com>.
André Warnier wrote:
> dirk ooms wrote:
>> Andre,
>>
>> thanks for your thoughts on this. i agree that this issue brings me to
>> 'a loop of increasing contradictions'. it's probably good to go one
>> step back and explain the real-life requirement:
>>
>> we have an application that is used by many small companies, each
>> company has its own data and can have multiple users (typically 1 to 5).
>> within a company there is a requirement to switch users in a fast way
>> (e.g. using a badge or a fingerprint). think of a restaurant having 1
>> computer and several waiters. we want to trace what is done by which
>> waiter and there is also an incentive for the waiter to switch users
>> because his fee will be based on his logged activities.
>>
>> my reasoning was: i'll keep the standard proven AAA mechanism for the
>> initial log in, but allow fast user switching within a company where
>> there is more trust between users (which is security-wise probably a
>> weak statement). still there is a need for some type of authentication
>> because the users can have different roles. but this indeed leads to
>> conflicts between the standard and the proprietary
>> authentication/authorization mechanism.
>>
>> my current reasoning is: i need to keep a standard proven AAA mechanism
>> also for fast user switching. correct? but how do i tackle this given
>> that we now have form/container-based authentication. do i need a
>> parallel standard container-based mechanism? what mechanism exists that
>> allows to authenticate by scanning a barcode (i.e. a single (possibly
>> long) string)? any pointer/suggestion will be much appreciated.
>>
>
> So, if I understand correctly :
> - the first level of authentication is, say, by company, and is meant
> basically to avoid some unauthorised people accessing the website of
> each customer
> - the second level of authentication is within this company's dedicated
> website, and is meant to distinguish between different "actors" within
> that website.
> - and within the website, there is an incentive for the actors to use
> their own id, and not someone else's when they do something
>
> As far as the "within the one website" thing is concerned, the other
> suggestions that you have received seem the way to go. How you really
> integrate that into each action that these people do, I don't know really.
> But I would imagine that you could have some kind of applet within your
> web pages, which reads a barcode from a barcode reader, and adds what it
> has read as a POST parameter, before it submits the form to the server.
> And then on the server, you pick up this special parameter, and switch
> the userPrincipal on-the-fly, as they say.
>
> As far as the first-level authentication is concerned, here is maybe a
> bit of lateral thinking :
> If you put an Apache httpd front-end in front of Tomcat, then you could
> install some form of standard authentication at the Apache httpd level,
> which protects that website "in general" with the "company login". Then
> only if that authentication succeeds, you would proxy the calls to
> Tomcat (using mod_jk for instance). But Tomcat would know nothing about
> this front-end authentication, and would not need to know.
> Similarly, Apache httpd would never know - nor need to know - when the
> user at the Tomcat level changes.
>
> I think such a scheme would keep things nicely separated, and simplify
> the whole design.
>
Upon further thinking, of course you would not necessarily need an Apache httpd front-end
for this, and could do this all within Tomcat.
The container-level authentication comes first, before your webapp is even called.
So that is your Tomcat-level authentication, by company.
Then you could still have some servlet filter (which runs after the container-level
authentication) to pick up this special POST parameter and do your "application-level"
authentication.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by André Warnier <aw...@ice-sa.com>.
dirk ooms wrote:
> Andre,
>
> thanks for your thoughts on this. i agree that this issue brings me to
> 'a loop of increasing contradictions'. it's probably good to go one
> step back and explain the real-life requirement:
>
> we have an application that is used by many small companies, each
> company has its own data and can have multiple users (typically 1 to 5).
> within a company there is a requirement to switch users in a fast way
> (e.g. using a badge or a fingerprint). think of a restaurant having 1
> computer and several waiters. we want to trace what is done by which
> waiter and there is also an incentive for the waiter to switch users
> because his fee will be based on his logged activities.
>
> my reasoning was: i'll keep the standard proven AAA mechanism for the
> initial log in, but allow fast user switching within a company where
> there is more trust between users (which is security-wise probably a
> weak statement). still there is a need for some type of authentication
> because the users can have different roles. but this indeed leads to
> conflicts between the standard and the proprietary
> authentication/authorization mechanism.
>
> my current reasoning is: i need to keep a standard proven AAA mechanism
> also for fast user switching. correct? but how do i tackle this given
> that we now have form/container-based authentication. do i need a
> parallel standard container-based mechanism? what mechanism exists that
> allows to authenticate by scanning a barcode (i.e. a single (possibly
> long) string)? any pointer/suggestion will be much appreciated.
>
So, if I understand correctly :
- the first level of authentication is, say, by company, and is meant basically to avoid
some unauthorised people accessing the website of each customer
- the second level of authentication is within this company's dedicated website, and is
meant to distinguish between different "actors" within that website.
- and within the website, there is an incentive for the actors to use their own id, and
not someone else's when they do something
As far as the "within the one website" thing is concerned, the other suggestions that you
have received seem the way to go. How you really integrate that into each action that
these people do, I don't know really.
But I would imagine that you could have some kind of applet within your web pages, which
reads a barcode from a barcode reader, and adds what it has read as a POST parameter,
before it submits the form to the server.
And then on the server, you pick up this special parameter, and switch the userPrincipal
on-the-fly, as they say.
As far as the first-level authentication is concerned, here is maybe a bit of lateral
thinking :
If you put an Apache httpd front-end in front of Tomcat, then you could install some form
of standard authentication at the Apache httpd level, which protects that website "in
general" with the "company login". Then only if that authentication succeeds, you would
proxy the calls to Tomcat (using mod_jk for instance). But Tomcat would know nothing
about this front-end authentication, and would not need to know.
Similarly, Apache httpd would never know - nor need to know - when the user at the Tomcat
level changes.
I think such a scheme would keep things nicely separated, and simplify the whole design.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by dirk ooms <di...@onesparrow.com>.
Andre,
thanks for your thoughts on this. i agree that this issue brings me to
'a loop of increasing contradictions'. it's probably good to go one
step back and explain the real-life requirement:
we have an application that is used by many small companies, each
company has its own data and can have multiple users (typically 1 to 5).
within a company there is a requirement to switch users in a fast way
(e.g. using a badge or a fingerprint). think of a restaurant having 1
computer and several waiters. we want to trace what is done by which
waiter and there is also an incentive for the waiter to switch users
because his fee will be based on his logged activities.
my reasoning was: i'll keep the standard proven AAA mechanism for the
initial log in, but allow fast user switching within a company where
there is more trust between users (which is security-wise probably a
weak statement). still there is a need for some type of authentication
because the users can have different roles. but this indeed leads to
conflicts between the standard and the proprietary
authentication/authorization mechanism.
my current reasoning is: i need to keep a standard proven AAA mechanism
also for fast user switching. correct? but how do i tackle this given
that we now have form/container-based authentication. do i need a
parallel standard container-based mechanism? what mechanism exists that
allows to authenticate by scanning a barcode (i.e. a single (possibly
long) string)? any pointer/suggestion will be much appreciated.
dirk
>
> Without going into the technique itself, from your description above it looks to me as if
> this is a scenario so different from what a standard AAA mechanism is designed to achieve,
> that you are going to find yourself getting into a loop of increasing contradictions, if
> you try to fit this into the standard authentication mechanisms.
> (In other words : you are going to be using code that has been carefully designed and
> perfected to do things well in one scenario, and try to do something else with it. I
> would expect all kinds of side-effects, and an endless series of patches upon patches to
> avoid them).
>
> Maybe the first question to ask : why do you need the user to be authenticated /to the
> servlet container/ in the first place ? when, and for what, do you use the return values
> of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down)
>
> If you rethink the above, imagining that the user-id is just a request parameter like any
> other <form> parameter (*), and that Tomcat itself has no knowledge of an authenticated
> user, what breaks down ?
>
>
>
> (*) which according to your own explanation above, you are going to have to do at some
> point anyway.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: user switching or application interacting with container based
authentication
Posted by André Warnier <aw...@ice-sa.com>.
dirk ooms wrote:
> Hello,
>
> we are running a web application with form based authentication. we now
> have a requirement to switch between users (for subsets of users) with a
> minimum of user interaction (log out and log in providing username &
> password is way too much work for the user). so i was thinking of
> providing each user with a badge with a unique barcode (a hash of
> username&password?) which they can scan into a dedicated field in the
> webpage and which will trigger the user switch. note that this barcode
> field will only be available once a person has logged in in the normal
> way (form based), so the user switch request is received within an
> authenticated session.
>
> the difficult part of the story is how can i tell the 'container based
> authentication' that the current session is transferred to another user
> with possibly other roles OR how can i create a new session for the new
> user (so applying the correct authorization and providing a
> HttpServletRequest returning the correct values of getUserPrincipal()
> and isUserInRole()). the application is able to retrieve the user and
> its roles, but how can the application inform the container about this.
>
> i've been googling and reading for hours now and i'm a bit lost
> (understatement) on how to proceed with this. it could also be the case
> that there are much better scenario's than the one i have in mind.
>
> any hint on fast-user-switching or
> applications-interacting-with-container-based-authentication are very
> welcome.
>
Without going into the technique itself, from your description above it looks to me as if
this is a scenario so different from what a standard AAA mechanism is designed to achieve,
that you are going to find yourself getting into a loop of increasing contradictions, if
you try to fit this into the standard authentication mechanisms.
(In other words : you are going to be using code that has been carefully designed and
perfected to do things well in one scenario, and try to do something else with it. I
would expect all kinds of side-effects, and an endless series of patches upon patches to
avoid them).
Maybe the first question to ask : why do you need the user to be authenticated /to the
servlet container/ in the first place ? when, and for what, do you use the return values
of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down)
If you rethink the above, imagining that the user-id is just a request parameter like any
other <form> parameter (*), and that Tomcat itself has no knowledge of an authenticated
user, what breaks down ?
(*) which according to your own explanation above, you are going to have to do at some
point anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org