Shibboleth service provider for multiple websites

[Peter Schober]

* asikbcc <shiblyxp at gmail.com> [2018-04-26 12:25]:
> I have following configuration for a website https://site1.example.com. After
> the authentication is done the user is redirected to
> https://site1.example.com/auth/shibboleth/callback. So far this is working
> just fine. However, I need to configure shibboleth service provider for
> another website  https://site2.example.com and after successful
> authentication the user should be redirected to
> https://site2.example.com/auth/shibboleth/callback. How can I do this?

How did you get it to work for the one vhost?
That's how you'd do it for the other vhost.

>        <InProcess logger="native.logger">
>           <ISAPI normalizeRequest="true" safeHeaderNames="true">
>              <Site id="1" name="site1.example.com"/>
>           </ISAPI>
>        </InProcess>
>      
>        <UnixListener address="shibd.sock"/>

Is this on MS-Windows using the MS-IIS web server? (ISAPI stuff above)
Or is this on UNIX (socket listener)?

>        <RequestMapper type="Native">
>            <RequestMap applicationId="default">
>               <Host name="site1.example.com"/>
>            </RequestMap>
>         </RequestMapper>

What web server is this? You don't need the request map with Apache
httpd, for example.

>        <ApplicationDefaults entityID="https://site1.example.com/shibboleth"
>                             REMOTE_USER="eppn persistent-id targeted-id"
>                             homeURL="site1.example.com"

You're setting homeURL to what should be default anyway if RelayState
was lost, so don't.

>             <SSO entityID="https://login.example.com/shibboleth">
>                 SAML2
>             </SSO>
>      
>              <SessionInitiator type="Chaining"
>                                Location="/Login"
>                                id="Intranet"
>                                relayState="cookie"

That whole config is a mess, but I don't think that matters much for
this question.

>           <CredentialResolver type="File"
>                               key="/etc/ssl/private/xca_www.key"
>                              
> certificate="/etc/apache2/ssl/www-chain-2018.pem"/>

There is no upside to re-using the browser-facing TLS certificate for
HTTPS to secure SAML protocol messages, which are never seen by a
browser.
There are downsides, though. (Confusion about the trust model, and
usually renwals based on the business model for selling commercial TLS
certs, not security assessments of your deployment.)

-peter