Assurance Enhancements for IdPv2

[William G. Thompson, Jr.]

On Fri, May 17, 2013 at 6:15 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 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

Thanks for the link.  At first glance it looks like one might be able
to write a V3 authentication flow that delegates to Spring Security or
Shiro or whatever for primary authentication as long as authN flow
translates the results back to the V3 contract appropriately.

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

Yes, it would be good to stay in alignment if possible.  One of the
discussion points at IIW was building something of a V3 facade that
would hide V2 complexity from the MCB and make it more future-proof.

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

Just call it AOP and it becomes sexy.  :)


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

Cool...I'll capture that as well as well as the authN apis as possible
collaboration points.

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

Really appreciate the feedback.

Best,
Bill


>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net