SP: Assertion contains an unacceptable AudienceRestriction.

[Rainer Hoerbe]

As usual, thank you for the swift and helpful response.

May I suggest improvements for the NativeSPApplicationOverride page on the wiki?
First it would be helpful to separate concept ("Valid and Invalid Reasons" and the first part of "Host vs. Path" from the rest. Second I think that the "Host vs. Path" concept could be renamed to "Host-only vs. Path" and give following example:

Application 1 root context

Application 2 root context

Apps organized by

https://a1.example.org/

https://a2.example.org/

Host-only

https://a1.example.org/secure/

https://a2.example.org/secure

Path

https://a.example.org/a1/

https://a.example.org/a2/

Path

 

- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120921/c611cbfc/attachment-0001.html