Chris, thanks so much. But please bear with me. I'm in the slow
group I think I have a pretty good handle on creating the
authenticator. But take me from the top, using manager as an example.
In the web.xml file it has login auth-method set to BASIC. I'm assuming
that invokes BasicAuthenticator. But I don't see a value configured in
any context file for BasicAuthenticator unless I'm just missing it. If
I wanted to change manager to use my authenticator, would I need to
change web.xml's auth-method to "malcolm"? I figured I would change the
web.xml auth-method and then change the default BasicAuthenicator value
to my own authenticator valve. But I can't find it. Do I add this
context/valve to the host definition in server.xml, to the
/conf/context.xml, to the Catalina default-context.xml or does it
matter? Sorry I'm not getting it. I've been with TC for many years.
But this is an area I've never dealt with until now.
On 10/5/2021 1:54 PM, Christopher Schultz wrote:
Jerry,
On 10/5/21 12:23, Jerry Malcolm wrote:
hi Chris, thanks for the feedback.
I'm not using JWTs. I'm just sending a base64 token made up of
"a:b:c:d:e". I don't mind cloning the BasicAuthenticator if that's
what's required. I'm still not understanding how TC will handle my
modified header.
It won't. You'll have to do that yourself.
I assume that if TC finds an Authorization header with the word
Basic, it will route to the standard BasicAuthenticator class.
If that's been configured, yes.
What would I do in order to tell TC if it finds an auth header with
the word "Malcolm" as the prefix instead of "Basic" that it should
route to my custom Authenticator class?
You'd have to install your own Authenticator (a Valve) in your
. markt posted how to do this on 10/2 in this thread.
You can look at how the BasicAuthenticator does things to orient
yourself. Feel free to extend BasicAuthenticator and override whatever
you need. Ultimately, it will need to do whatever you need it to do
and then set a Principal on the request (and/or session). Again,
looking at the BasicAuthenticator source will help a lot.
-chris
On 10/5/2021 9:50 AM, Christopher Schultz wrote:
Jerry,
On 10/4/21 22:40, Jerry Malcolm wrote:
I really don't care whether it's called Basic, Malcolm,
RollYourOwn, or whatever. I was just emulating techniques I've had
to implement as a client for credit card gateways and other
services in the past that all use BASIC prefix with their own token
definition. I can easily rename the Authorization header prefix
or not even call the header "Authorization". The main thing is
there is a base64 token associated with it. Our application has a
mobile app with a rather large REST api. The security requirements
of this product far exceed id:pw authentication. We have
additional pre-shared keys, timestamps, and other undisclosed data
built into the raw token that is converted to base64 and added to
the header. This REST api authentication is implemented and working
without problems.
Here's the situation. There is a certain amount of user data that
is not yet displayable in the current version of the mobile app.
We have a couple of links to the main web site where the user can
view the remainder of their data. I don't want to throw up a login
screen when a user, who is already logged into the app, clicks the
link to view the data that is on the web site. But I also want to
maintain the same level of security as we have with REST to
establish the session. The server already knows how to
authenticate from the REST api tokens. I simply want to use the
same token and the same auth code to "login" the user and create a
session just like I can do with request.login( id, pw ), but using
my own authentication code from the auth header token.
Sounds like you are using JWTs.
Something that Tomcat doesn't currently allow you to do (because
it's not supported by the Servlet Spec) is just shove a Principal
into the container and say "here you go".
This would be immensely helpful for any kind of SSO mechanism. I
have build 3 different SSO mechanisms into my product, and I can do
it because I'm not using Tomcat's container-provided authentication.
I would really REALLY like to get away from what I'm using and back
into more "mainstream" principal management.
I think I'll bring this onto the dev@ mailing list because I've been
waiting far too long to make this move.
An earlier post suggested I just implement a CredentialHandler,
which would be great. But it looked like the credential handler is
given "id/pw" extracted from the base64. Or will it actually
return whatever it finds in the base64 token? "A:B:C:D:E:F"
instead of "id:pw"? If it does just return the base64 decoded
string, that would definitely make it much simpler to implement,
but then that would still require I use "Basic" as the prefix in
order for all of the normal tomcat auth he
