Customization of Authentication Request handling

[Cantor, Scott]

On 2/4/14, 6:58 PM, "Aleksandar Likic" <aleksandar.likic at securekey.com>
wrote:

>Thanks. Thinking about it, my custom login handler would have a GUI,
>meaning dealing with things like properly handling browser back button.

You can do what you like, but the IdP will always trap that as an error,
so what you do doesn't really matter in that respect.

> Clicking on the back button to go back to my hypothetical login page
>would probably cause the browser to resubmit authentication request from
>SP, right?

No, it will cause a replay error.

> One way to solve it would be having a redirect before the login page
>(following POST-REDIRECT-GET pattern) but I'd like minimize redirects and
>use forwards instead. I guess, in order to achieve something like this I
>would have somehow to tell Shibboleth that it is OK to accept repeated
>request from RP in this scenario?

If you want to disable replay checking, you can do that, but it won't fix
anything, there are other steps that will fail.

> Perhaps based on the fact that we are in the middle of processing this
>exact request? I am guessing that this functionality is not out of the
>box and I would have to implement it myself? Are there any security
>implications with this approach?

That depends on many different factors. It traps the user in a loop of
repeated logins, instead of clearly showing that they can't do what
they're trying to do. And it throws off login statistics by doing so as a
side effect when people bang on it.

-- Scott