Re: [OT] Specifying a Custom Authenticator Class
Jerry, On 10/6/21 15:09, Jerry Malcolm wrote: 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. You didn't miss it. If there are no Valves configured for the application (in META-INF/context.xml), then Tomcat will use the from WEB-INF/web.xml to choose the right one to use. Since you have BASIC in there, Tomcat automatically (and silently) adds BasicAuthentiator to the Manager web application. If I wanted to change manager to use my authenticator, would I need to change web.xml's auth-method to "malcolm"? No, you can leave this BASIC, or remove it entirely. It doesn't really matter. 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. Yep, just add a to your META-INF/context.xml which specifies your custom authenticator as the class name. Hope that helps, -chris 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 &qu
Re: [OT] Specifying a Custom Authenticator Class
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 impleme
Re: [OT] Specifying a Custom Authenticator Class
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 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 userna
Re: [OT] Specifying a Custom Authenticator Class
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. I assume that if TC finds an Authorization header with the word Basic, it will route to the standard BasicAuthenticator class. 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? Thx 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 y
Re: [OT] Specifying a Custom Authenticator Class
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
st
Re: Specifying a Custom Authenticator Class
Mark,
On 10/5/21 04:46, Mark Thomas wrote:
On 05/10/2021 03:40, Jerry Malcolm wrote:
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"?
CredentialHandler only gets passed the password.
Yes, but if the (base64-decoded) token from the user looks like:
username:a:b:c:d:e
Then the credential handler will get "a:b:c:d:e" as the "password".
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"?
Probably not that much. Looking at Tomcat's BasicAuthenticator you'd
have to override most of it to do this anyway so I'd probably copy it as
the starting point and then edit it.
+1
-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
Re: Specifying a Custom Authenticator Class
On 05/10/2021 03:40, Jerry Malcolm wrote:
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"?
CredentialHandler only gets passed the password.
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"?
Probably not that much. Looking at Tomcat's BasicAuthenticator you'd
have to override most of it to do this anyway so I'd probably copy it as
the starting point and then edit it.
Mark
Just exploring my options.
Thanks for the discussion. It's helping me a lot.
Jerry
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
Re: Specifying a Custom Authenticator Class
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.
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"?
Just exploring my options.
Thanks for the discussion. It's helping me a lot.
Jerry
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
Re: Specifying a Custom Authenticator Class
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
Re: Specifying a Custom Authenticator Class
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. M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Jerry, On 10/1/21 20:48, Jerry Malcolm wrote: 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: "Extending from AuthenticatorBase is a great idea, and you can avoid Tomcat's standard authenticator by configuring your authenticator as a in your application's META-INF/context.xml file." That is precisely what I want to do. But I cannot find any documentation on how to configure a different authenticator class in a context.xml file. I'm sure I'm just missing it, or I'm using totally incorrect words in the googe searches to find it. Can someone please point me to the documentation for this? How is your header value different from typical HTTP Basic? You may be able to get away with an implementation of the CredentiaHandler instead of the Authenticator. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
On 02/10/2021 01:48, Jerry Malcolm wrote: 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: "Extending from AuthenticatorBase is a great idea, and you can avoid Tomcat's standard authenticator by configuring your authenticator as a in your application's META-INF/context.xml file." That is precisely what I want to do. But I cannot find any documentation on how to configure a different authenticator class in a context.xml file. I'm sure I'm just missing it, or I'm using totally incorrect words in the googe searches to find it. Can someone please point me to the documentation for this? http://tomcat.apache.org/tomcat-10.0-doc/config/valve.html#Authentication Your Valve needs to implement Authenticator (which it will if you extend AuthenticatorBase) so Tomcat knows it is providing authenticator rather than just a regular Valve. You'll end up with something like: Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Specifying a Custom Authenticator Class
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: "Extending from AuthenticatorBase is a great idea, and you can avoid Tomcat's standard authenticator by configuring your authenticator as a in your application's META-INF/context.xml file." That is precisely what I want to do. But I cannot find any documentation on how to configure a different authenticator class in a context.xml file. I'm sure I'm just missing it, or I'm using totally incorrect words in the googe searches to find it. Can someone please point me to the documentation for this? Thx, Jerry
Re: Add custom Authenticator in context.xml
I guess it's for OAuth2. I'm using apache OAuth2 module and AJP in Tomcat. That's just great to externalize authentication out of the application, it works well, avoid bad design by nature ... but : - OAuth2 is mostly defined for an application authentication while in JEE the authentication mecanism are mostly serveur side. - java frameworks trend to code or put everything inside the app, while JEE protected it keeping it outside of the app (in the container) Message initial De: Thomas Meyer Répondre à: Tomcat Users List À: users@tomcat.apache.org Objet: Add custom Authenticator in context.xml Date: Sat, 4 Jul 2020 20:54:17 +0200 Hi, a while ago I did write a little POC of how to add a customauthenticator scheme to tomcat. this is what I did come up with: https://github.com/thomasmey/BearerTokenAuthenticator It's rather complicated solution!Is there an more easy solution to add a custom authenticator scheme to a Context/context.xml? Mfgthomas --- --To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.orgFor additional commands, e-mail: users-h...@tomcat.apache.org
Re: Add custom Authenticator in context.xml
Am 6. Juli 2020 14:14:59 MESZ schrieb Mark Thomas : >On 04/07/2020 19:54, Thomas Meyer wrote: >> Hi, >> >> a while ago I did write a little POC of how to add a custom >> authenticator scheme to tomcat. >> >> this is what I did come up with: >> https://github.com/thomasmey/BearerTokenAuthenticator >> >> It's rather complicated solution! >> Is there an more easy solution to add a custom authenticator scheme >to a Context/context.xml? > >How about: > >1. Extract the Authenticators.properties file from catalina.jar > (or from source) >2. Edit it to reference the custom Authenticator >3. Place it at $CATALINA_BASE/lib/org/apache/catalina/startup >4. Add the JAR with the custom authenticator to $CATALINA_BASE/lib > >which would make it generally available to use in WEB-INF/web.xml Okay, understand! Nice trick. > >Or > >1. Add it directly to context.xml as: > > > className="de.m3y3r.catalina.authenticator.BearerTokenAuthenticator" /> > Ah, okay an Authenticator is also a Valve, I didn't think about this! I will play around with this setup a bit. thanks for the hint! > >which you would need to do for each app that wants to use it (or set it >in the global web.xml for all apps). > >Mark > >- >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
Re: Add custom Authenticator in context.xml
On 04/07/2020 19:54, Thomas Meyer wrote: > Hi, > > a while ago I did write a little POC of how to add a custom > authenticator scheme to tomcat. > > this is what I did come up with: > https://github.com/thomasmey/BearerTokenAuthenticator > > It's rather complicated solution! > Is there an more easy solution to add a custom authenticator scheme to a > Context/context.xml? How about: 1. Extract the Authenticators.properties file from catalina.jar (or from source) 2. Edit it to reference the custom Authenticator 3. Place it at $CATALINA_BASE/lib/org/apache/catalina/startup 4. Add the JAR with the custom authenticator to $CATALINA_BASE/lib which would make it generally available to use in WEB-INF/web.xml Or 1. Add it directly to context.xml as: which you would need to do for each app that wants to use it (or set it in the global web.xml for all apps). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Add custom Authenticator in context.xml
Hi, a while ago I did write a little POC of how to add a custom authenticator scheme to tomcat. this is what I did come up with: https://github.com/thomasmey/BearerTokenAuthenticator It's rather complicated solution! Is there an more easy solution to add a custom authenticator scheme to a Context/context.xml? Mfg thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom Authenticator
Am Mittwoch, den 01.06.2016, 09:29 -0400 schrieb Christopher Schultz: > Thomas, > > On 6/1/16 7:15 AM, Thomas Meyer wrote: > > > > Hi, > > > > How do I get a custom mapping set in > > ContextConfig.setCustomAuthenticators? ( > > https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/st > > art > up/ContextConfig.html#setCustomAuthenticators(java.util.Map) > > > > > > > ) > > > > > > I want to add a custom mapping for lets say BEARER to a my > > Authenticator. I searched the source code but nobody seems to call > > this method. So how and where should this map be configured? > Do you mean that you want to replace FORM or CLIENT-CERT in web.xml > with BEARER and have it use your authenticator? > > Would you be okay if you just ignored the and installed > your own authenticator? Because you can do that just by registering > your CustomAuthenticatorValve in your valve chain for your > application. Hi, I came up with this solution: 1.) use custom host implementation in conf/server.xml in add className="de.m3y3r.catalina.core.CustomStandardHost" attribute 2.) webapp's web.xml - add login-config BEARER OAuthRealm Apply security-constraint as usual. use role "**" if you just want authentication. 3.) in webapp's context.xml define a suitable realm https://localhost:8080/path/to/endpoint; clientId="username" clientSecret="password"/> Code is here: https://github.com/thomasmey/BearerTokenAuthenticator Feedback is welcome. with kind regard Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom Authenticator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas, On 6/1/16 7:15 AM, Thomas Meyer wrote: > Hi, > > How do I get a custom mapping set in > ContextConfig.setCustomAuthenticators? ( > https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/start up/ContextConfig.html#setCustomAuthenticators(java.util.Map) > > ) > > I want to add a custom mapping for lets say BEARER to a my > Authenticator. I searched the source code but nobody seems to call > this method. So how and where should this map be configured? Do you mean that you want to replace FORM or CLIENT-CERT in web.xml with BEARER and have it use your authenticator? Would you be okay if you just ignored the and installed your own authenticator? Because you can do that just by registering your CustomAuthenticatorValve in your valve chain for your application. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldO40AACgkQ9CaO5/Lv0PBKCwCgkPlnOXK1U01agZ152xdQrKbr NKcAoMI1CZZUZf5cSVLvN4cZ75Ho5+qf =njpx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Custom Authenticator
Hi, How do I get a custom mapping set in ContextConfig.setCustomAuthenticators? ( https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/startup/ContextConfig.html#setCustomAuthenticators(java.util.Map) ) I want to add a custom mapping for lets say BEARER to a my Authenticator. I searched the source code but nobody seems to call this method. So how and where should this map be configured? With kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Custom Authenticator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel, On 8/14/2009 2:24 PM, Daniel Stephens wrote: For Security reasons, We need to do logging for IP,username, etc(AUDIT). We need to log success and failed attempts. We don't want to modify the internal classes(unless it's impossible). Tomcat cannot do this out of the box, which is why we switched to securityfilter (http://securityfilter.sourceforge.net/). If you write your own Realm, you can do anything you want with the database. If you get the current CVS head, you can also get access to the request that performs the authentication, so you can write things like error messages (or tokens) into the request attributes for later display. Yes, the CVS head is safe to use :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqSqSEACgkQ9CaO5/Lv0PAHawCfbLq1ZZVOgK/8QcH4Vfx4ZFjc Z24An2YhOhbEs8mENrLwzeusIuYmmNUo =DXsR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Custom Authenticator
Need some help or advice.. For Security reasons, We need to do logging for IP,username, etc(AUDIT). We need to log success and failed attempts. We don't want to modify the internal classes(unless it's impossible). We are using the FORM auth-method, we POST to j_security_check. We have our own custom realm that extends RealmBase. All that works fine. Until we try and report back to the browser why the authentication failed, to many attempts, account expired etc.. So my question is. Since the authentication occurs in the Realm/FormAuthenticator, Has anyone been able to successfully extend this class ( FormAuthenticator ), and implement this kind of concept? I have found some examples online, but I have not been able to make them work. thanks...
Re: Tomcat Custom Authenticator
Daniel Stephens wrote: Need some help or advice.. For Security reasons, We need to do logging for IP,username, etc(AUDIT). We need to log success and failed attempts. We don't want to modify the internal classes(unless it's impossible). We are using the FORM auth-method, we POST to j_security_check. We have our own custom realm that extends RealmBase. All that works fine. Until we try and report back to the browser why the authentication failed, to many attempts, account expired etc.. The Tomcat API deliberately won't let you do that. It is bad security to explain why the authentication failed as it nearly always makes brute force attacks easier. So my question is. Since the authentication occurs in the Realm/FormAuthenticator, Has anyone been able to successfully extend this class ( FormAuthenticator ), and implement this kind of concept? I have found some examples online, but I have not been able to make them work. You would have to so some fairly serious surgery to the Tomcat internals to get this to work. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help required for writing custom Authenticator
This is why it is rare to write a custom Authenticator. More often you
write a custom Realm to do this sort of thing. You only need an
Authenticator if you have some non-standard way of extracting the user
credentials from the Request.
The problem with the code below is that it doesn't call
request.setUserPrincipal(Principal) when you successfully authenticate, and
doesn't call response.sendError() when it fails. These two steps are
required by the Authenticator contract (see the comments in the invoke
method of AuthenticatorBase). This is why you are getting the 403 error.
After your Authentictor's authenticate method returns true, Authenticator
base passes the request off to the hasResourcePermission method of RealmBase
(in o.a.c.realm). This will use the Principal in the Request to determine
what roles the user has, and since in your case it is null, Tomcat decides
she has no roles.
The easiest way to fix your code is to create a GenericPrincipal (also in
o.a.c.realm), and set it as the Request's Principal on success. This can
optionally wrap a custom Principal, which is what the webapp will see when
it calls request.getUserPrincipal(). You should use the register method of
AuthenticatorBase to do this if you want to support SSO. Otherwise, you
only need to call request.setAuthType and request.setUserPrincipal.
Mehmood, Qaiser [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
I need help to write my own custom Authenticator.
I wrote my own Authenticator and it's very simple and following is the
code:
public class SampleAuthenticator extends AuthenticatorBase {
public boolean authenticate(Request request,Response
response,LoginConfig config)
throws java.io.IOException{
// if authenticated against LDAP return true
otherwise return false
If(authenticated() == true) {
return true;
} else {
return false;
}
}
}
This Authenticated method is check with LDAP and put Admin in subject.
Is there any thing else I need to do in my custom authenticator?
But when I am executing this request, I am getting error HTTP Status
403 - Access to the requested resource has been denied.
My web.xml configuration is :
security-constraint
web-resource-collection
web-resource-nameTest/web-resource-name
descriptionTest
/description
url-pattern/protected/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameAdmin/role-name
/auth-constraint
/security-constraint
login-config
auth-methodMyAuth/auth-method
realm-namesampleTest/realm-name
/login-config
Thanks,
Qaiser Mehmood
Work (512) 248-4269
Cell (571) 438-8639
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom Authenticator
You can also implement custom LoginModule according to the JAAS specification. JAAS tutorial and LoginModule example is included in the JDK documentation. | -Original Message- | From: Arash Bijanzadeh [mailto:[EMAIL PROTECTED] | Sent: Thursday, February 02, 2006 7:21 AM | To: users@tomcat.apache.org | Subject: Custom Authenticator | | | Hi, | I need to implement my custom authenticator to do some extra | comfig i user session beside the authentication. How can I | achive this? Is there a way to do authentication besides | rigid j_check_security? | | -- | from debian manifesto: | Debian Linux is a brand-new kind of Linux distribution. | Rather than being developed by one isolated individual or | group, as other distributions of Linux have been developed in | the past, Debian is being developed openly in the spirit of | Linux and GNU. | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom Authenticator
Hi, I need to implement my custom authenticator to do some extra comfig i user session beside the authentication. How can I achive this? Is there a way to do authentication besides rigid j_check_security? -- from debian manifesto: Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU.
Re: Custom Authenticator
Have You thought about a request filter? All it has to do is watch for authenticated sessions that are missing some critical session attributes. Fill in the missing info as needed. -David Arash Bijanzadeh wrote: Hi, I need to implement my custom authenticator to do some extra comfig i user session beside the authentication. How can I achive this? Is there a way to do authentication besides rigid j_check_security? -- from debian manifesto: Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom Authenticator in tomcat 4 ?
Hi, Is it possible to have a custom Authenticator in tomcat 4.1? I can't find any information about it, only for 5x. I have tried configuring a WEB-INF/context.xml with a valve referencing my authenticator class, works well in tomcat 5.5, but not in 4.1 (which is currently the version we are running in production). Do I have to upgrade to make this work? Thanks /Andreas
