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

Scott Koranda skoranda at gmail.com
Sun Dec 18 16:06:10 EST 2016


Hi,

I am using SP 2.6.0 with Apache 2.4.

My use case has 4 configured virtual hosts. Each one is configured like this
in Apache:

<VirtualHost>
  ServerName https://site1.myserver.com
  ServerAlias *.site1.myserver.com
  UseCanonicalName On

  ...

</VirtualHost>

The other 3 are the same with site1 replaced by site2, site3,
site4.

Each of the virtual hosts has well over 100 other server aliases
that are registered in DNS and that resolve and are served
content by the server. For example

https://alias1.site1.myserver.com
https://alias2.site1.myserver.com
...
https://alias100.site1.myserver.com

https://alias1.site2.myserver.com
https://alias2.site2.myserver.com
...
https://alias100.site2.myserver.com

and so on.

I DO want all of the virtual hosts and their aliases to be ONE
single SP application (the default), where the notion of an application is defined at

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationModel

In short, after going through an SSO flow and establishing a
session that session should be available for every virtual host
and its aliases.

In shibboleth2.xml I have adjusted the <Sessions> element with

cookieProps="; path=/; secure; HttpOnly; domain=.myserver.com"

and the handlerURL is not set and so it assumes the default
"/Shibboleth.sso".

Each of the <VirtualHost> elements contains 

<Location "/Shibboleth.sso">
  SetHandler shib
</Location>

and I do find that I can reach

https://alias1.site1.myserver.com/Shibboleth.sso

for all of the alias and virtual host combinations as I expect.

The use case only uses passive protection and sessions are
initiated like this:

https://site1.myserver.com/Shibboleth.sso/Login?target=https://alias2.site3.myserver.com

That is, the handler used is always

https://site1.myserver.com/Shibboleth.sso/Login

but the target could be any of the many alias and virtual host
combinations.

The reason to always use 

https://site1.myserver.com/Shibboleth.sso/Login

to initiate sessions is that I thought I would only need to
register in the metadata one set of ACS URLs, ie.

https://site1.myserver.com/Shibboleth.sso/SAML2/POST

The issue, however, is that the SP computes the ACS URL that it
includes in the <AuthnRequest> using the value from the target.
For example, with the target

https://site1.myserver.com/Shibboleth.sso/Login?target=https://alias2.site3.myserver.com

the <AuthnRequest> will include

AssertionConsumerServiceURL="https://alias2.site3.myserver.com/Shibboleth.sso/SAML2/POST"

This surprises me.

First, I would have expected the SP to construct the ACS URL
based on the handler that was used to invoke the session
creation.

Second, if the SP is computing the ACS URL I would have thought
that the use of

UseCanonicalName On

would have forced it to use

https://site1.myserver.com

as the scheme:host combination. Nowhere in the Apache
configuration is

alias1.site3.myserver.com

configured so I am surprised that the SP computes it.

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?

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

Or am I missing something more fundamental?

Thanks,

Scott K


More information about the users mailing list