Shibboleth Developers

["Alistair Young" <>]

> What you're doing is inventing yet another proprietary SSO protocol behind
> a SAML gateway. It's not novel, but it is (unfortunately, IMHO) common.
yep. It's a sign of the creativity that's abundant in our profession ;)

It's quite common in messaging systems to have an identifier passed around
unmodified, for tracking state etc. It's just that over HTTP everyone's
happy with cookies. Our use case won't work with cookies, hence the handle
approach.

> Use separate providerIds and handle your own protocol interactions
not sure what you mean by separate providerIds. Shibb can only handle one
at a time.

> you're responsible for the trust model behind the gateway
absolutely - that's taken care of

We could do all this easily but there's no point if it doesn't work when
talking to a standard shibb origin.

What I'm really suggesting is a small extension to the Shibboleth profile
to allow for more flexible implementations but a simpler solution might be
to use the "target" parameter and add a GET param to it. That way the SP
can pick it up when the AuthenticationStatement arrives.

In effect, the SP is bouncing state information off the IdP in the form of
an opaque handle that only it knows about.

It should work as long as the origin doesn't filter off GET params from
the "target" before posting the response.

Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

>> The guard redirects to the WAYF, whose location is returned by the
>> engine via a web service. The guard sets the shire parameter to point
>> to the engine, not the guard. The engine then gets the
>> AuthenticationStatement, not the guard.
>
> What you're doing is inventing yet another proprietary SSO protocol behind
> a
> SAML gateway. It's not novel, but it is (unfortunately, IMHO) common. In
> general, you're responsible for the trust model behind the gateway, not
> SAML.
>
>> The point of the handle, originally sent to the IdP in the Shibboleth
>> GET request, is for the guard to identify itself. This handle ends up
>> in the SAML Response coming from the IdP to the engine.
>
> If you want the internal entities exposed to the IdP, IMHO they should be
> SPs, period. They need their own identity in the protocol.
>
>> Ideally we'd want the handle to end up in a SAML element in the SAML
>> Response containing the AuthenticationStatement. That way an engine
>> knows which guard it's working on behalf of.
>
> Use separate providerIds and handle your own protocol interactions behind
> the gateway. Do not expose them to the standard components, who don't
> really
> want to know about them and shouldn't have to.
>
> -- Scott
>
>