SP: Assertion contains an unacceptable AudienceRestriction.

[Rainer Hoerbe]

Aha, my first misconception was that path-based would mean vhost1//path-for-app1 and vhost//path-for-app2. However, it includes vhost1/path-for-app2 and vhost1/path-for-app2 .

- Rainer

Am 21.09.2012 um 18:24 schrieb "Cantor, Scott" <cantor.2 at osu.edu>:

> On 9/21/12 12:17 PM, "Rainer Hoerbe" <rainer at hoerbe.at> wrote:
>> 
>> This is my default SP:
>> <ApplicationDefaults id="default" policyId="default"
>> entityID="https://samlecho2.hoerbe.at/shibboleth" ... >
>> 
>> The assertion is being delivered to the ACS if the specified entityID.
> 
> Well, that's the problem. The ACS maps to the "default" id and so the
> audience it's looking for is above. The one it has is based on the request
> to the IdP which was triggered by a request to content that's mapped to a
> different applicationId.
> 
>> Why should this be path-based? My ssl.conf contains:
> 
> Your configuration is applying the applicationId based on path, /secure.
> That's a path based override. That's never going to work unless you define
> a set of ACS endpoints living inside /secure, which is what the
> documentation describes in the override material about having to create a
> second handlerURL.
> 
> If you want the override to be based on vhost (looks like you're using TLS
> SNI?), set the applicationId property at the vhost level outside the
> Location block, or create a <Location /> block for the whole site.
> 
> That is a much better idea, and means you don't need a separate
> handlerURL, since the vhost itself will take care of discriminating
> everything.
> 
>>> Yes, but the ACS doesn't map to the same applicationId as the resource
>>> that generated the request.
>> 
>> I cannot see why. What do I have to look for?
> 
> Just look in native.log, turn up RequestMapper category, and you'll see it
> map your POST requests to the wrong applicationId.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net