Hi,
On Thu, Apr 21, 2016 at 9:51 AM, Stuart Douglas <sdouglas_at_redhat.com> wrote:
> > 5. There's no way for the application when using
> > HtppServletRequest#authenticate to strongly indicate it wants to start a
> new
> > dialog vs resuming/continuing an existing one.
>
> Can you give a concrete example of exactly what you mean by this? You
> keep mentioning FORM auth but I am not really sure how there is any
> ambiguity here?
FORM was mentioned just as an example, since it's well known and has a
strong concept of the application indicating that it wants to continue the
dialog.
There's a potential for ambiguity mostly when using custom authentication
mechanisms.
Consider a slightly modified version of the FORM authentication mechanism
that instead of posting to j_security_check, allows the application to put
the {username, password} credentials in request scope and then somehow
invoke the authentication mechanism.
How will this "somehow invoke" be done?
The only API available for that today is request#authenticate. This will
indeed invoke the mechanism and it can consume the credentials and forward
or redirect to the original destination (which has been saved when the
authentication dialog started).
But now suppose the user abandons the flow (by navigating away from the
login form), and somewhat later explicitly attempts to login.
How does the mechanism now know a new login is requested and all previous
kept state (i.e. the saved destination) should be erased?
Without counter measures what happens is that the mechanism may try to
display an error page (thinking the caller was still in the middle of the
dialog and didn't provide credentials), or it may redirect the user
erroneously to the page the user earlier tried to access but now isn't
interested in anymore, or anything in between.
In general, when custom mechanisms and even more so when multiple custom
mechanisms are used, you don't know what state those mechanism(s) might be
keeping.
> When you post to j_security_check you
> will always be authenticated, and then redirected as appropriate.
>
But here it concerns one (known) mechanism defined by Servlet, and this
particular known mechanism has no support to let an application continue
the dialog other than by posting to j_security_check.
The "problem" here is perhaps that request#authenticate is not only used to
invoke the 4 well known mechanisms defined by the Servlet spec, but is also
used to invoke any number of custom mechanisms (among which but not
restricted to those using JASPIC).
> I'm not sure where in the cycle your proposed new methods would be
> called, and what effect they would have?
>
The "continue" variant of the authenticate() method would be called by the
application when in the middle of a dialog (conversation, cycle, ...). Its
effect would be that the mechanism uses its state and the data provided by
the application to further that dialog. Note that "data" does not
necessarily means "credentials". As part of a multi-step dialog this data
could just as well be a choice for a device to be used for 2-factor
authentication, or an OAuth provider for an OAuth2 authentication mechanism
etc).
The "new" variant of authenticate would be called by the application when
it wants to discard any potential state the authentication mechanism may
have and "start over". It can be called at either the start of the dialog
or when in the middel of it.
Kind regards,
Arjan Tijms
>
> Stuart
>