You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Malcolm <te...@malcolms.com> on 2021/10/02 00:48:26 UTC
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: Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Posted by Mark Thomas <ma...@apache.org>.
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:
<Context>
<Valve className="my.custom.Authenticator" />
</Context>
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-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
>>
>
>
> ---------------------------------------------------------------------
> 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: Specifying a Custom Authenticator Class
Posted by Mark Thomas <ma...@apache.org>.
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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
<auth-method> 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 <Valve> 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
>> <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-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
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Specifying a Custom Authenticator Class
Posted by Jerry Malcolm <te...@malcolms.com>.
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
> <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-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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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: [OT] Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Specifying a Custom Authenticator Class
Posted by Jerry Malcolm <te...@malcolms.com>.
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 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-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
>>
>
> ---------------------------------------------------------------------
> 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: [OT] Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Posted by Jerry Malcolm <te...@malcolms.com>.
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-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: Specifying a Custom Authenticator Class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org