>>>>> On Tue, 19 Apr 2016 15:17:36 -0700 (PDT), arjan tijms <arjan.tijms_at_gmail.com> said:
AT> The Servlet specification currently has a HttpServletRequest#authenticate()
AT> method. Its Javadoc says:
AT> "Use the container login mechanism configured for the ServletContext to
AT> authenticate the user making this request."
AT> It doesn't explicitly say it with so many words, but in practice this boils
AT> down to a *mandated* authentication (the "login mechanism" must
AT> authenticate) and it's implicitly taken to start a *new* authentication
AT> dialog/interaction with the caller.
The API is certainly imperative in that the act of calling the
authenticate() method causes authentication to happen.
AT> I found however that there's also a use case where the application needs to
AT> indicate that an existing authentication dialog should be *continued*.
AT> Often this is in combination with the application providing some data
AT> (typically credentials).
AT> E.g.
AT> * Caller accesses protected resource
AT> * Authentication mechanism forwards to login page
AT> * Login page posts back to itself
AT> * The application runs validators on the postback (e.g. using bean
AT> validation)
AT> * The application wants to signal the authentication mechanism to continue
AT> the authentication process with the (validated) data
AT> The following code shows an example of this:
AT>
https://github.com/javaee-security-spec/soteria/blob/master/test/app-mem-customform/src/main/java/test/LoginBacking.java#L76
AT> Now in JSR 375 we can work around this somewhat by wrapping
AT> request#authenticate and setting some flags as request attributes, but I
AT> think this use case may potentially warrant being pushed down the Servlet
AT> spec.
AT> This would mean a new method or methods, along the lines of a
AT> HttpServletRequest#authenticateContinue(Map<String, Object> parameters) and
AT> HttpServletRequest#authenticateNew(Map<String, Object> parameters), or
AT> perhaps HttpServletRequest#authenticate(boolean newAuth, Map<String,
Object> parameters), etc.
>>>>> 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.
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.
GW> I think the problem is that you are trying to mix application managed
GW> authentication with container managed authentication, and it is going to be
GW> difficult to pass any partial results without assuming a mechanism.
GW> or am I missing something still?
>>>>> On Wed, 20 Apr 2016 13:47:15 +0200, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> What I'm using here is simply the programmatic equivalent of that. I think
AT> it's exactly as fragile or limiting as the existing " {j_username,
AT> j_password} -> /j_security_check" way to continue the authentication dialog
AT> is. It just gives the application an opportunity to inspect/validate the
AT> credentials before continuing that dialog, but otherwise (conceptually)
AT> there should not be any differences.
AT> But, in general there are multiple issues with the authenticate() method:
AT> 1. Letting the application be very strict about wanting (or expecting) to
AT> continue a dialog (such as when a FORM-like mechanism delegates the login
AT> form to the application) vs the application wanting to abandon any
AT> potentially existing dialog (such as when a user clicks on a login button)
AT> 2. Providing parameters with the authenticate() call. (for JSR 375 I want
AT> to propose to use the generic Credential type for the SecurityContext; a
AT> Credential is the super class of any other type of more specific
AT> credentials)
AT> 3. The return value of HttpServletRequest#authenticate - not mentioned in
AT> this thread yet, but it may be good to start a separate discussion about it
AT> ;)
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.
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017