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
<Context>. 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 header processing to work to send to my custom
credential handler, correct? I realize that renaming the header
prefix to "Malcolm" or whatever would be more architecturally pure.
But how much more code is involved to get the same result if my
authorization header prefix is now "Malcolm" instead of "Basic"?
If your Authorization header isn't formatted like this, then you can
forget using the BasicAuthenticator without modification:
Authorization: base64(stuff + ":" + more stuff)
If you use a CredentialHandler, you'll only get the password and
whatever is in the user-database as the "password" for the matching
user. You won't get the actual username in the CredentialHandler.
But if your header is formatted enough like HTTP Basic and you can
match input-password (or whatever) against the stored credential
without the username, then maybe you can get away with only a
CredentialHandler.
-chris
On 10/4/2021 8:49 AM, Christopher Schultz wrote:
Michael,
On 10/3/21 11:58, Michael Osipov wrote:
Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a
specialized encoding of the authToken. I have been scouring
google for info. I found one post where the answer included the
statement:
This would clearly violate Basic auth scheme and the according RFC.
I highly recommend against. Don't abuse Basic. Create your own
scheme/header and solve your problem with it.
This is a very good point.
Instead of:
Authorization: Basic [base64stuff]
Using "Bearer" might be a better choice, though that is also covered
by a specific RFC and might be confusing to overload that token
("Bearer") for another purpose.
You could just do:
Authorization: Malcolms [token]
If you are going to write a custom authenticator, anyway. You'll
need to have a custom client, of course, but you will already have
that kind of thing because no standard HTTP client would format your
authentication tokens in this way.
Another dumb question: why use your own custom stuff instead of the
standard(s)?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
