Attempt to spoof header (Shib-Cookie-Name) was detected

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-10-04 17:52]:
> The problem with this is that we can't do that because the App that
> is protected is Liferay and use fqdn to know wich "site" it will
> shows. So in the liferay, we have set-up a site for siteA and it
> would cost us a lot to duplicate it to another one with hostname
> siteb and maintained it. That's why we try to make URL rewriting.
[...]
> I want to add http://siteA that will have the same content as siteB
> and should have the same protection from Shibboleth.

So both sites should have the same content and the same protection.
Why have two vhosts/"sites" then? Only to pre-select a SAML IDP? Why
not federate the same SP with the same resource for everyone (same
host, same metadata) and either use IDP Discovery (preferred, as it
supports bookmarking the resource) or force the IDP to use
IDP-initiated SSO (which is pretty similar to having to know /your/
IDP-specific vhost; instead the IDP could host such a URL itself).

So the whole problem of separate sites/vhosts and Liferay and cookies
etc. seems to be unnecessary.

Not sure this matters, but it seems Liferay can be configured with a
defualt vhost and a default "community", which seems like all you need
here: You want every request to go to the same resource anyway, so no
changes for Liferay should be necessary.
http://stackoverflow.com/a/33419670 also suggests no virtual hosts
need to be set up in Liferay if you want the content to be the same.

* reda sabir <sabiretude at gmail.com> [2016-10-04 17:47]:
> Let's assume siteA is portal.example.com and siteB is
> theportal.example.com.  This two fqdn have the same root
> (example.com) so I configure the domain of the cookie as example.com
> so I can have SSO between the two sites.

Subjects from any IDP can access all vhosts (because it's the exact
same content everywhere, anyway)? Then why create IDP-specific vhosts?
As said above there are easier ways to deal with IDP selection (offer
an IDP Discovery Service or have the IDP host the resource that
initiates SSO).

* reda sabir <sabiretude at gmail.com> [2016-10-04 17:50]:
> I can't do that because Liferay (the framework of the application
> protected) use the fqdn of the request to show the result. So if I
> had just used a reverse proxy configuration instead of rewriting
> URL, it won't work because portal.example.com is not developped in
> Liferay. So, we have to fork the implementation and each time we
> change a site, we need to do the same for the other which is a lot
> work and a bad idea too.

Even if all that were true I doubt it's significant extra work
compared to the extra work you cause for yourself on the SAML side.
-peter