Handling 'dynamic' parameter in ACS url

[Maharaj, Sudhir]

Hi,

We are working on a SAML2 integration with a vendor and have had limited success. Problem is in our IDP, for the vendor sp-metadata we have only configured a single endpoint.

SP metadata configured for vendor has the following:
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST" 	Location="https://vendor.domain/samlAuth/SSOActions?awr=1& amp;realm=BU-T" index="1" isDefault="true"/>
</md:SPSSODescriptor>

The signed AuthnRequest received contains AssertionConsumerServiceURL= "https://vendor.domain/samlAuth/SSOActions?awr=1&amp;realm=BU-T" .
Good for first time access. Repeated access/combination of accesses increases the value of the awr parameter. This doesn't match our configured metadata and correctly results in 
Error Message: No peer endpoint available to which to send SAML response

Looking up SAML2 spec we asked the vendor do one of 3 things
 - always send AssertionConsumerServiceIndex=1 instead of AssertionConsumerServiceURL with parameter that increments.
 - use RelayState for all parameters
 - don't send any ACS

The vendor is not able to implement any of the proposed options and suggested we add multiple ACS locations in our metadata file. Clearly this isn't ideal seeing there is no real magic number.

While it appears the vendor implementation might not be according to SAML2 spec, how best do you think to proceed to implement this integration? Is there a way to 'wildcard' (for lack of a better term)  ACS or something similar? Anyone else have similar issue integrating with vendor SAML2 implementations?

Thanks in advance
Sudhir
Boston University IS&T