Shibboleth Developers

["Alistair Young" <>]

> each entity should have a providerId
I see what you mean. The providerId that gets sent to the IdP is never
returned to the SP though. Unless it gets put into an <Audience>? Or maybe
it does - what's your thoughts?

The first thing the gateway, as you put it, knows about a Shibboleth
session is when an AuthenticationStatement from an IdP arrives. The
gateway didn't initiate this. A guard did that. If the Audience contained
the Guard's providerId that would solve the problem.

The only way I can see of sending something to an IdP's SSO and having it
returned in the SAML Response is if the providerId is returned as an
Audience.

Otherwise it'll have to be the shire with the Guard's providerId added as
another param:

http://idp.url?shire=http://shire.url?providerId=666&target=...&time=...

so the SAML Response gets POSTed to http://shire.url?providerId=666

a combination of POST and GET - bit weird but it should work ok without
modifications to any existing deployments, I think.

Alistair


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

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