Shibboleth Developers

["Scott Cantor" <>]

> 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.

That's what TARGET is for. I think you're tracking more than state. If the
value is used for some security purpose, you can't just pass it around
unless it has transactional association with the signed data coming back
(i.e. as you ask, it has to be in the assertion). That's simply not possible
now.

TARGET will be returned, but has no binding to the message. I can substitute
a valid signed response for any target value I want if I interrupt the POST
or artifact redirect.

> > 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.

Shibboleth can handle many at a time. That's what 90% of the code is about,
dynamically figuring out who/what/where/how.

I say again, if you want to do this stuff well, each entity should have a
providerId, and if you want the gateway to speak on behalf of all of them,
that's fine. You can figure out how to determine when the gateway should act
as what entity.

> 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.

TARGET is the right place, but I believe it may not work for your use case.

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

It's opaque. But I think you may be exposing yourself to a security problem.
TARGET is only suitable if the state information being recovered does not
have a threat model if it's recombined with the wrong SAML assertion by an
attacker.

-- Scott