* Palle Girgensohn <
gir...@pingpong.net> [2013-01-30 12:31]:
> The SP in this case I Shibboleth. And it has privacy
> implications. It should probably jot be accessible on the idp. I had
> hoped I would be able to send the RealyState back together with an
> entityid parameter, but this does not seem to work. Leaves me with
> the option to set up proper DS.
Maybe I misspoke. It doesn't matter what the value of the RelayState
is. Assuming authnRequests are nore signed you could either construct
your own AuthenRequest to the other IDP (in the name of the SP),
sticking the RelayState in there, or, if the other IDP supports it,
start an IDP-initiated flow pointing to the SP (though I'm not sure
this can include the RelayState since technically with IDP-initiated
there cannot be state at the SP).
So try to figure out how to get at the RelayState parameter within the
SSP API first, IMHO still got options to make this work the way you
intened to.
> A question here, are there any good docs for setting up an Idp
> centric DS. I.e it should default to a specific idp, that should be
> implicitally remembered as the preferred choice for this user, and
> on the *login page* for the primary idp, there would be an option to
> choose another IdP, or chose from a list, using DS.
With SAML2 DS the flow is from SP -> DS -> SP -> IDP (i.e., from DS
back to the SP) so where this is hosted would be irrelevant as long as
it's accessible without any state or as part of a protocol exchage (so
the IDP's login page probably does't qualify).
Any DS worth mentioning will be able to default to one IdP and also
remember a subject's previous choice. It's just the part where you
want this to happen on the IdP login page that might prove to be
difficult. But maybe it's not.
-peter