11:34 a.m.
Accessing an unprotected area triggers our custom
AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:36 a.m.
I guess I should say, accessing a URL not protected by a
security-constraint still triggers our custom AuthenticaitonMechanism.
On 11/14/2013 12:34 PM, Bill Burke wrote:
Accessing an unprotected area triggers our custom
AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:15 a.m.
This is by design. Basically authenticate() will always be called, but sendChallenge()
will only be called if authentication is actually required, or if the user supplied
credentials that were actually invalid.
Basically the thinking is that is is better to authenticate, so if you are logging
requests or whatever you can see who is actually performing them.
Is this causing you problems? Originally we had a way to disable this behaviour, but it
seems to have been lost along the way.
Stuart
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: undertow-dev(a)lists.jboss.org
Sent: Thursday, 14 November, 2013 6:34:58 PM
Subject: [undertow-dev] Unprotected areas still trigger auth
Accessing an unprotected area triggers our custom
AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
6:05 a.m.
On 15/11/13 08:15, Stuart Douglas wrote:
This is by design. Basically authenticate() will always be called,
but sendChallenge() will only be called if authentication is actually required, or if the
user supplied credentials that were actually invalid.
Basically the thinking is that is is better to authenticate, so if you are logging
requests or whatever you can see who is actually performing them.
Is this causing you problems? Originally we had a way to disable this behaviour, but it
seems to have been lost along the way.
The option should still be there although we may not be exposing it.
Just finishing off some CLI tasks and I am hoping my next task will be
to complete the authentication mechanism config that I discussed of
various lists quite a while back now.
This option should be a part of that.
Stuart
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Thursday, 14 November, 2013 6:34:58 PM
> Subject: [undertow-dev] Unprotected areas still trigger auth
>
> Accessing an unprotected area triggers our custom
> AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
6:59 a.m.
sendChallenge is still called.
On 11/15/2013 3:15 AM, Stuart Douglas wrote:
This is by design. Basically authenticate() will always be called,
but sendChallenge() will only be called if authentication is actually required, or if the
user supplied credentials that were actually invalid.
Basically the thinking is that is is better to authenticate, so if you are logging
requests or whatever you can see who is actually performing them.
Is this causing you problems? Originally we had a way to disable this behaviour, but it
seems to have been lost along the way.
Stuart
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Thursday, 14 November, 2013 6:34:58 PM
> Subject: [undertow-dev] Unprotected areas still trigger auth
>
> Accessing an unprotected area triggers our custom
> AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:04 a.m.
On 15/11/13 12:59, Bill Burke wrote:
sendChallenge is still called.
That should only be happening if the mechanisms indicated during the
authenticate step that it wanted a challenge to be sent.
As an example the DIGEST mechanism may want to do this if it receives a
stale nonce.
On 11/15/2013 3:15 AM, Stuart Douglas wrote:
> This is by design. Basically authenticate() will always be called, but
sendChallenge() will only be called if authentication is actually required, or if the user
supplied credentials that were actually invalid.
>
> Basically the thinking is that is is better to authenticate, so if you are logging
requests or whatever you can see who is actually performing them.
>
> Is this causing you problems? Originally we had a way to disable this behaviour, but
it seems to have been lost along the way.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: undertow-dev(a)lists.jboss.org
>> Sent: Thursday, 14 November, 2013 6:34:58 PM
>> Subject: [undertow-dev] Unprotected areas still trigger auth
>>
>> Accessing an unprotected area triggers our custom
>> AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
7:09 a.m.
On 11/15/2013 8:04 AM, Darran Lofthouse wrote:
On 15/11/13 12:59, Bill Burke wrote:
> sendChallenge is still called.
That should only be happening if the mechanisms indicated during the
authenticate step that it wanted a challenge to be sent.
What is the indication? Sending back NOT_AUTHENTICATED?
As an example the DIGEST mechanism may want to do this if it receives
a
stale nonce.
4
The problem is my oauth mechanism has no way to know if there is another
mechanism or if the request is even supposed to be authenticated. If
there is not appropriate information in the request, it sends back
NOT_AUTHENTICATED and performs a redirect to the auth server in
sendChallenge.
Maybe I'm just using the SPI wrong. I'll take a look at Basic auth again.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:14 a.m.
If the required tokens were not within the message then the mechanism
should return NOT_ATTEMPTED.
If there are multiple mechanisms (or even a single mechanism) and
authentication is required but all the mechanisms return NOT_ATTEMPTED
then Undertow will take the decision to turn the request around and call
sendChallenge on each of them.
NOT_AUTHENTICATED means the mechanism saw 'something' in the incomming
requets and attempted to authenticate it but for some reason failed so
the message flow needs reversing and the challenges sending. This could
happen as an example if stale nonce is received in DIGEST.
Regards,
Darran Lofthouse.
On 15/11/13 13:09, Bill Burke wrote:
On 11/15/2013 8:04 AM, Darran Lofthouse wrote:
> On 15/11/13 12:59, Bill Burke wrote:
>> sendChallenge is still called.
>
> That should only be happening if the mechanisms indicated during the
> authenticate step that it wanted a challenge to be sent.
>
What is the indication? Sending back NOT_AUTHENTICATED?
> As an example the DIGEST mechanism may want to do this if it receives a
> stale nonce.
> 4
The problem is my oauth mechanism has no way to know if there is another
mechanism or if the request is even supposed to be authenticated. If
there is not appropriate information in the request, it sends back
NOT_AUTHENTICATED and performs a redirect to the auth server in
sendChallenge.
Maybe I'm just using the SPI wrong. I'll take a look at Basic auth again.
Bill
9:27 a.m.
On 11/15/2013 8:14 AM, Darran Lofthouse wrote:
If the required tokens were not within the message then the
mechanism
should return NOT_ATTEMPTED.
If there are multiple mechanisms (or even a single mechanism) and
authentication is required but all the mechanisms return NOT_ATTEMPTED
then Undertow will take the decision to turn the request around and call
sendChallenge on each of them.
NOT_AUTHENTICATED means the mechanism saw 'something' in the incomming
requets and attempted to authenticate it but for some reason failed so
the message flow needs reversing and the challenges sending. This could
happen as an example if stale nonce is received in DIGEST.
Awesome. I misinterpreted how to pass back Outcomes. Returning
NOT_ATTEMPTED at the appropriate time seemed to fix this problem. I'll
close the JIRA.
THanks,
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:03 a.m.
On 14/11/13 17:34, Bill Burke wrote:
Accessing an unprotected area triggers our custom
AuthenticationMechanism. Is this by design or by spec mandate? Or a bug?
Design but it can be disabled, we may still need to expose the option
however.
There are two reasons for this: -
1 - Authentication mechanisms based on mechanism specific processes
once authentication has commenced, e.g. DIGEST where the nonce count is
incremented on each request or the client or server are signing the request.
2 - Regular user demand that the authenticated identity is available
to the web app even when the non secured resources are accessed.
3830
days inactive
3831
days old
9 comments
3 participants
participants (3)
-
Bill Burke -
Darran Lofthouse -
Stuart Douglas