Hi,
Thanks for your effort to help this JSR move forward. This week in Berlin
the JCP EC proposed an official statement towards Oracle about asking for a
clear road-map and mission statement about Java EE 8. Including an offer to
help where that's accepted by Oracle. Let's see how it goes, hopefully help
by you and others is appreciated and not thrown away or forced into another
kind of community project ("aka fork" as some see it, and unless it becomes
a fragmentation of Java EE which could be even worse, that is what might
happen if no wise decisions are made here in a timely manner)
Cheers,
Werner
On Thu, May 12, 2016 at 6:20 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> As mentioned in the discussion earlier, I went ahead and introduced a
> parameter to signal a "new" authentication is required by the application.
> It has been added in this commit:
> https://github.com/javaee-security-spec/soteria/commit/f264a177c9a9318a96e4e971e91f35c1fabf66f2
>
> The LoginToContinueInterceptor now makes use of this as of this commit:
> https://github.com/javaee-security-spec/soteria/commit/d05041c53816bea76c9e1226f96ad1b084dcae82
>
> A bean would use this as follows:
>
> @Inject
> private SecurityContext securityContext;
>
> AuthStatus status = securityContext.authenticate(
> getResponse(),
> withParams()
> .newAuthentication(true)
> .credential(new UsernamePasswordCredential("foo", "secret")));
>
> As of now it's just a parameter and an authentication mechanism is free to
> honor it or ignore it. It could potentially be enforced a little bit
> stronger by introducing a new clearState() method on the
> AuthenticationMechanism interface (with a default that does nothing).
>
> I'll try to add a new sample application later that demonstrates how a
> login-to-continue (container initiated) and a new (caller initiated) login
> can be done in the same application. An OAuth2 mechanism would most clearly
> demonstrate the issues here, but that's obviously harder to do in a simple
> sample, so I plan to start with a custom form.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
> On Mon, Apr 25, 2016 at 10:57 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Apr 25, 2016 at 12:55 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
>>
>>> So the use-case you are concerned about is that if a user directly
>>> navigates to the login form, either via a bookmark or a link from a
>>> not protected page in the application, then calling authenticate()
>>> might see some state (most specifically the original destination) from
>>> a previous invocation.
>>>
>>
>> Indeed, that would be one instance of the problem.
>>
>>
>>
>>> Well I can see that could be a problem, but I'm not sure that it is
>>> only related to the authenticate() method. Pure FORM authentication
>>> suffers from the same issue without the use of a call to authenticate.
>>>
>>
>> True, it's not unthinkable that depending on how pure FORM is exactly
>> implemented a similar problem occurs there as well. (I'm not sure if the
>> Servlet spec says anything about directly posting the configured login page
>> to j_security_check without having been redirected or forwarded to it
>> before)
>>
>>
>>
>>> Maybe the solution it to describe what behaviour should be when the
>>> login form sees a referrer field that differs from any save
>>> destination. If we said that if the referrer field is present, then
>>> it should replace any saved destination, would that fix your issue?
>>>
>>
>> Not exactly, unfortunately, since that would (perhaps) only work for the
>> Servlet defined FORM. The issue I'm seeing (and actually encountered a
>> couple of time, among others when building zeef.com), is more general
>> and mostly applies to custom mechanisms.
>>
>> For example, with an OAuth2 mechanism you may present a /login page
>> letting the user choose between providers Google, Twitter and Facebook in
>> step 1. This choice is put in the session. Then a timestamp is put in the
>> session as well (csrf protection), and the user is redirected to the
>> provider. Then the user arrives back at /login, and the mechanism uses its
>> state to determine it's a valid callback, contacts the provider back
>> (server to server), receives a "profile" (user data), which is put in the
>> session again. The mechanism may see that the profile is incomplete (e.g.
>> no email, like in Twitter's case), and direct the user to a form for
>> entering the email. If the email is entered, the user is redirected to the
>> original destination, where the mechanisms finds the complete profile in
>> the session and uses it to establish the authenticated identity, clears all
>> state and the dialog ends.
>>
>> As you can see there's a few points where things are put in the session
>> and a few points where the user can navigate away.
>>
>> For instance, the user can navigate away from the provider (not log in
>> there), or the user can be redirected back to the application's /login with
>> some kind of error that the application displays, and then navigate away,
>> or the user can navigate away when on the mentioned page for entering the
>> missing data (email) is presented, etc.
>>
>> Fixing this with heuristics is quite difficult and error prone (we tried
>> at zeef.com, didn't work well), but for somewhat simpler mechanisms it
>> indeed may work.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>>
>>> regards
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>>>
>>
>>
>