Shibboleth Developers

["Scott Cantor" <>]

> 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