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
>>
>
>