Hi,
> >>>>> On Wed, 20 Apr 2016 20:34:34 +1000, Greg Wilkins <gregw_at_webtide.com>
> said:
>
> GW> The problem I see is the opacity of this. authenticate() currently
> works
> GW> because it has no idea what credential (if any) exist in the
> GW> request/session/connection, but it assumes that if they are there they
> were
> GW> set by a previous encounter with the configured authentication
> mechanism,
> GW> and thus it will know what to do.
>
> Thanks for stating the design intent so succinctly.
>
It is correct, but it's not the full story. What's explained here is how
the authentication mechanism is supposed to obtain credentials from the
caller.
It doesn't explain however how an application is supposed to make the
distinction between wanting to start a new authentication dialog and
continuing an existing one.
As for request#login that was mentioned, I forgot to mention earlier that
this is not only limited to a very specific credential, but it's also not
supposed to invoke the authentication mechanism at all.
From the javadoc:
"Validate the provided username and password in the password validation
realm used by the web container login mechanism configured for the
ServletContext."
In this context it means that it's supposed to go straight to the "password
validation realm" (identity store) used by the login (authentication)
mechanism. E.g. if the authentication mechanism configured would be FORM
and the proprietary identity store would be "database identity store", this
call would go directly to that database identity store.
>
> GW> So in your example, the application some how knows (or assumes) that
> GW> authentication is using JASPIC (I'm assuming that is what
> GW> defines IS_AUTHENTICATION and AUTH_PARAMS ??), but I think that is
> fragile
> GW> and/or limiting.
>
> In other words, that may not be a valid assumption.
>
I'm not sure I understand this one. Can you explain why it may not be a
valid assumption?
I mentioned that with the existing FORM mechanism all assumptions are
exactly the same. I.e. if I rephrase Greg's words using that:
GW*> So in [FORM], the application some how knows (or assumes) that
GW*> authentication is using [a Servlet authentication mechanism] (I'm
assuming that is what
GW*> defines j_security_check and {j_username, j_password} ??), but I think
that is fragile
GW*> and/or limiting.
EB> In other words, that may not be a valid assumption.
So are we not saying here then that the existing Servlet FORM
authentication is fragile and/or limiting and that having it is not a valid
assumption?
Or am I missing something here/misunderstood the above?
> I'm concerned about the complexity of this new API. I agree the
> existing API has the problems you state, but I'd like to see JSR-375 get
> a little further along before we consider making changes to the Servlet
> spec for this.
>
That seems fair enough. It's absolutely not necessary to have any API
changes in the short term, but I do wonder if the problem is sufficiently
understood.
I'll try to summarise it:
1. Somewhat implicitly Servlet has always made the distinction between an
"authentication mechanism" and an "identity store". The former interacts
with the caller, the latter only validates the credentials.
2. HttpServletRequest#login is supposed to go straight to the identity
store, it's limiting with respect to the supported credentials. Because the
identity store has not been standardised before it's very server specific
what happens exactly here.
3. HtppServletRequest#authenticate is supposed to "trigger" the
authentication mechanism, it's designed to obtain the credentials in a
mechanism specific way (obtain them from e.g. request attributes, data
previously stored in the session, from a header in the current request, by
challenging the caller, etc)
4. Authentication mechanisms not rarely call back to the application, and
the application has to do a specific action afterwards to resume the
authentication dialog (e.g. postback to j_security_check).
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.
Hope this makes it more clear.
Kind regards,
Arjan Tijms
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
>