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