Assurance Enhancements for IdPv2

[Cantor, Scott]

On 5/17/13 3:00 PM, "William G. Thompson, Jr." <wgthom at gmail.com> wrote:
>
>Our initial thought is first build a LoginHandler that is essentially
>a bridge to SWF and then craft the MCB functionality there.
>
>So the first question is, what do folks think of this approach generally?

That would be my inclination.

>Once in SWF, the thought occurred to us that we might be able to
>leverage Spring Security or Shiro for primary authentication rather
>than come up with a replacement for the LoginHandler API.  Thoughts?

I don't think much of any authentication API I've ever seen, but I have no
experience with either.

There are no plans to reuse anything like that as a core interface in V3.
The design work on that so far is here:

https://wiki.shibboleth.net/confluence/display/IDP30/Authentication+and+Ses
sion+Management

I don't know how possible it will be to create a subset of what will be in
V3 for use by a plugin, but I suppose it might be feasible. In that event,
the eventual authentication code for V3 could be the basis of the same
code here.

>Other thoughts about leveraging/reusing the existing LoginHandlers in
>light of the MCB?   Does this seem feasible?

The LoginHandler API now relies on calling a static method on a fixed
class to return control. Short of an ugly hack like method interception or
something like that, I don't know how one could reuse them. The only real
value in doing so is to support existing custom handlers, because the
built-in ones just aren't that valuable to reuse.

>One key requirements is the ability to configure a mapping between
>various AuthNContexts and their authentication methods as well as the
>various AuthNContexts that would satisfy others (e.g. Silver satisfies
>Bronze).  Thoughts on where/how to manage this configuration?

Yeah, not in handler.xml, or at least not by extending that schema. For
V3, we will have a predicate layer that answers those questions in a
pluggable way, so one option might be to work on that interface sooner and
then write web flow code in this project to call into that interface.

>Any other thoughts on potential implementation paths, things that
>could be particularly difficult, etc?

The hardest/wonkiest bit is the context/method stuff that you already
mentioned.

The existing system already accomodates letting a LoginHandler honor any
context class it wants and return any one of them. The limiting issue is
with the existing LoginHandlers and their behavior.

-- Scott