Shibboleth Developers

[Scott Cantor <>]

> Hmm, I'm not an expert on this, but it's my impression that 
> if a browser/app interaction is supposed to be done via a 
> GET, turning it into a POST is likely to break things.  More 
> generally I think the Shib model is that the post-POST 
> redirection (as it were) uses whatever the original (or 
> application-desired) method is, in order to be as transparent 
> to the app as possible.  Shib doesn't currently support that 
> final method being a POST, but I think this is very desirable 
> at some point.  So we should design with this generality in 
> mind, IMHO.

I think the best model is to support some notion of RelayState (currently
possible via the TARGET parameter) in which the target runtime is
responsible for generating a state token that can be turned back into the
original browser request (whether GET or POST).

That way you can support session continuation across POST without shipping
sensitive data back to an origin site, or even revealing what URLs are being
accessed (which some have noted is a privacy hole in Shib today).

> I think we do, or we will eventually when logout is supported 
> in some form.  What are the operations provided by the 
> current ONC RPC interface?

Good point about logout. The current interface is roughly like a simple
session object with three methods:

        create()
        isvalid()
        getattributes()

The parameters aren't shown, but they include things like the session ID
(the this pointer in OO speak), the resource/application identifier, and the
various SAML bits such as during the create() call.

-- Scott