Shibboleth Developers

[Peter Williams <>]

Wouldn't this be done more properly by exploiting idp-proxying - so the 
handoff back to the initiating SP uses the standard protocol?

If folks were to use the protocol, then multi-vendor systems could cooperate. 
This seems more important these days given folks are applying specifically 
multi-factor authentication - with different factors authenticated by 
different vendor sub-systems.

When Shib IDP is talking to the SP, and the proxying Shib IDP talks to 
upstream to a non-Shib IDP (where the user updates her pin), the standard 
protocol rules for idp proxying would handle and maintain the SAML session.

On the return leg, the proxying Shib IDP can still choose whether or not to 
intercept the flow and require the user to interactively re-authenticate - 
using the new pin - before releasing its own assertion to the SP.

One would expect signed requests to be used - between the proxying IDP and 
each authentication authority IDP in charge of one factor. Proxy scopes would 
also seem applicable.
________________________________________
From: Chad La Joie 
[]
Sent: Wednesday, July 01, 2009 9:59 PM
To: 

Subject: Re: [Shib-Dev] Invalidating IdP Session

Related to your question on the user list, this will get a lot easier
starting tomorrow.  I'm working on a helper class that basically gives
you access to everything you'd need in order to do this.

Paul Hethmon wrote:
> Ok, I¹ve got a need to have my Shib IdP recognize that a user needs to
> change their password and direct them to a SP to do that. The password
> change SP is not the same SP that they tried to access at first. What I
> would like to have happen is for Shib to authenticate them and send them to
> the password change SP as an authenticated user. However, I don¹t really
> want Shib to keep a session for them. Instead, I would prefer that once they
> complete the password change, they get directed to their original SP choice,
> bounce to the IdP, and then login with the new credentials.
>
> So, in my login handler, I can do everything there except for killing the
> Shib session. Looking through the developer docs and API¹s, it doesn¹t seem
> that that ability would be available to a login handler. I guess this is
> related in part to SLO and that can be a handler (though my promise to work
> on it has not gotten too far yet).
>
> So how far into Shib am I going to have to dig to do what I want?
>
> thanks,
>
> Paul
>
> -----
> Paul Hethmon
> Chief Software Architect
> Clareity Security, LLC
> 865.824.1350 - office
> 865.250.3517 - mobile
> www.clareitysecurity.com
> -----
>
> God does not play dice with the universe; He plays an ineffable game of his
> own devising, which might be compared, from the perspective of any of the
> other players, to being involved in an obscure and complex version of poker
> in a pitch dark room, with blank cards, for infinite stakes, with a dealer
> who won't tell you the rules, and who smiles all the time.
>
>  -- Terry Pratchett, Good Omens
>
>
>

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch