logout and misc Qs --shib idp

[William G. Thompson, Jr.]

On Mon, Nov 12, 2012 at 2:32 PM, Steven Carmody <Steven_Carmody at brown.edu>wrote:

> On 11/12/12 2:17 PM, Cantor, Scott wrote:
> > On 11/12/12 2:06 PM, "Steven Carmody"<Steven_Carmody at brown.edu>  wrote:
> >>
> >> I'm wondering if there might be some way to leverage the contract work
> >> that Unicon did on the IDP for Wisconsin in order to achieve this
> >> result.... since that work added spring webflow to the IDP ....
> >
> > I am aware of no such work being done, but if somebody wants to customize
> > the IdP to do this, they are more than welcome to.
>
> from Bill Thompson:
>
> > The code was released under open source license per SOW with Wisconsin
> and announced at the I2 membership meeting last fall.
> >
> http://events.internet2.edu/2011/fall-mm/agenda.cfm?go=session&id=10001976&event=1148
> >
> > The solution comes in two components:
> >
> > 1) IdP/SWF integration
> > https://github.com/dima767/Shibboleth-IDP-Postlogin-Filter
> >
> > 2) SWF that inplements
> > https://github.com/dima767/Shibboleth-IDP-Postlogin-Flow
>
> this code leverages SWF to allow an IDP to make an "access control"
> decision as to whether a user is authorized to access a particular SP.
> The plan was to use the code in conjunction with accessing SAML-enabled
> GOOGLE. Yes, access control at the IDP is wrong. Please pass this msg on
> to google ....
>
> >
> >> I don't know anything about the IDP's internal software architecture...
> >> but, charging ahead anyway -- might there be a way use Webflow to add a
> >> task at the end of IDP processing to disable setting the IDP session
> >> cookie, if the box were checked on the login page ? Just hoping ....
> >
> > No. Because the profile handling code uses the session to recover the
> user
> > identity. That is something we intend to change in V3 and this is why.
> >
>
> I'm wondering if someone from UNICON might offer an opinion as to
> whether the SWF addition would allow local custom code to run at the
> very end of the profile handler ? After the point when the profile
> handling code would need to recover the user identity ?


There is a  sequence diagram in the presentation that shows where the SWF
comes into the flow.  It is basically wedged in after the IdP
authentication handlers and before the profile handlers.

http://events.internet2.edu/2011/fall-mm/agenda.cfm?go=session&id=10001976&event=1148

This capability is well suited to implement custom behaviors in the IdP
that come after primary authentication, before SAML profile mechanisms, and
are mostly independent of the SAML spec per se.  Things like course-grained
authZ, terms of use, attribute release approval, etc.

That said, I believe there are more straight forward ways to implement the
behavior described for user-controlled SSO opt-out and IdP-only
logout mechanism (i.e. *not* SLO).

Unicon is willing to explore potential solutions with the community and
implement them under them our Cooperative Support
sustaining engineering budget.

Best,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20121113/a0f0ce65/attachment.html