SP computation of the ACS URL to include in <AuthnRequest>

Scott Koranda skoranda at gmail.com
Thu Dec 29 11:13:06 EST 2016


> > First, I would have expected the SP to construct the ACS URL
> > based on the handler that was used to invoke the session
> > creation.
> 
> I think it used to a really long time ago, but the result of
> that was people creating loops and wasting a lot of my time
> on the list asking about it over and over, so I changed it
> pretty far back to start computing the handlerURL for a
> target based on the target itself and not based on the
> current request's own URL.
> 
> To be honest, when I say "I changed it", I think that
> changed as far back as 2.0. If it was a change it came
> during 1.x or in the changes to get to 2.0. At least based
> on the history I see right now without real digging. Anyway,
> it's not recent at all is my point, this is just how it's
> worked for most of its life.

Thanks.

I have never encountered this issue when adding another ACS
URL to metadata was a problem and so just always solved it that way, and
because the ACS URL I was adding to metadata "made sense".

But for this use case I don't want to add many hundreds of ACS
URLs to metadata (I doubt the fed-ops want me to do that
either).

> > With the observed behavior, the indication is that I would
> > have to publish in metadata all possible alias and virtual
> > host combinations since the ACS URL put into the
> > <AuthnRequest> is being derived from the target.
> > 
> > Is that the case?
> 
> If you don't sign your requests. These vhosting cases
> basically assume that you're signing requests (and that you
> get the IdPs to allow that bypass).

I think it is unlikely the IdPs will allow that bypass. The SP
in question here wants to federate with as many IdPs available
in the eduGAIN aggregate as possible.

This is a REFEDs R&S SP/use case.

> > Or could I "pin" the ACS URL used by leveraging a SAML2
> > session initiator with an <AuthnRequest> template? Would
> > the ACS URL in the template be respected by the SP when
> > constructing the <AuthnRquest>?
> 
> It is not respected with a template, there's no option for
> that at the moment.

Yes, I confirm that. Thanks.

> I can see that for shared domain cases, it isn't necessarily
> the case that this behavior is desirable or useful, but that
> hasn't come up before.

Will you entertain an RFE? I understand that it will not be a
high priority.

Essentially I want (I think) a configuration option or some mechanism to
signal to the SP which ACS to use. Something like "I know what
I am doing, so please just use this ACS URL when constructing
the <AuthnRequest>".

Thanks,

Scott K


More information about the users mailing list