On 20/04/16 03:28, Greg Wilkins wrote:
>
>
> On 20 April 2016 at 08:17, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
>
> It doesn't explicitly say it with so many words, but in practice
> this boils down to a *mandated* authentication (the "login
> mechanism" must authenticate) and it's implicitly taken to start a
> *new* authentication dialog/interaction with the caller.
>
>
> This is not exactly how Jetty interprets this.
>
> Specifically we have a concept of deferred authentication, were
> credentials may have been supplied (by BASIC/DIGEST headers or be a part
> of a current session), but that have not been checked because the
> request did not match a security constraint with authentication
> requirements.
For that scenario that is one reason why we continue to give our
mechanisms the opportunity to authenticate even if the security
constraint was not met.
With DIGEST authentication there is always a window where the header
sent by the client could be used in a replay by someone else - if you
don't process those headers every time one is received you are making
that window bigger.
It is also another reason for splitting mechanisms in two as it allows
verification without the assumption there will be a challenge.
> In such cases, a call to authenticate will attempt a login with the
> credentials/session already available and thus will often be able to
> return true and not need to start a *new* authentication interaction.
>
>
> I found however that there's also a use case where the application
> needs to indicate that an existing authentication dialog should be
> *continued*. Often this is in combination with the application
> providing some data (typically credentials).
>
> E.g.
>
> * Caller accesses protected resource
> * Authentication mechanism forwards to login page
> * Login page posts back to itself
> * The application runs validators on the postback (e.g. using bean
> validation)
> * The application wants to signal the authentication mechanism to
> continue the authentication process with the (validated) data
>
> The following code shows an example of this:
> https://github.com/javaee-security-spec/soteria/blob/master/test/app-mem-customform/src/main/java/test/LoginBacking.java#L76
>
>
> Sorry I'm not following your example? I can see no call to
> authenticate() in that example code?
> Are you saying you want to authenticate without using a form target
> of /j_security_check ??? If so, isn't that what the login API is for?
>
> Can you explain in a little bit more detail... perhaps leaving out JSF
> and expressing it in pure Servlet API terms?
>
> regards
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com
--
Darran Lofthouse - Principal Software Engineer
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Michael O'Neill(Ireland), Paul
Argiry (US)