Simplesamlphp multisite setup apache vhost

[Vin Tastic]

Really need some help here. Off the bat, i have a LAMP server which i'm using to host multiple apache sites. RHEL 8.9, php 8.1. I have setup simplesaml php (SP) to authenticate against host IDP (Azure). I'm able to successfully authenticate one site at a time but anytime i'm trying to authenticate two sites, i get "unable to validate signature". For e.g. i have test1.example.com and test2.example.com. If i comment out the config for test1.example.com in the authsources under config, test2.example.com works and vice versa works as well. As soon as I enable both codes, test2.example.com works everytime and test1.example throws the unable to validate signature. The IDP is the same for both sites but i'm using different certificate for each site as setup by IDP.

I’m using different entity id’s and certificates for both sites.

SP config. (this is the exact config of test1.example.com and test2.example.com is exactly similar except the entity id, certs.

'test1-sp' => [ 'saml:SP',

    // The entity ID of this SP.

    'entityID' => 'https://sso.example.com',

    'privatekey' => 'saml.pem',

    'certificate' => 'saml.crt',

 

 

    // The entity ID of the IdP this SP should contact.

    // Can be NULL/unset, in which case the user will be shown a list of available IdPs.

    'idp' => 'IDP.azure.com', 

    'discoURL' => null,

 

    'proxymode.passAuthnContextClassRef' => false,

],

I have done everything and not sure what i'm doing wrong or if its even possible to have mulltiple sites authenticate against a single IDP when they are hosted on the same server.

Thanks in advance.

Edit: the IDP config for test 1 is

$metadata['IDP.azure.com'] = [

'entityid' => 'https://sso.example.com',

'contacts' => [],

'metadata-set' => 'saml20-idp-remote',

'SingleSignOnService' => [

    [

        'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',

        'Location' => 'IDP.azure.com/saml2',

    ],

    [

        'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',

        'Location' => 'IDP.azure.com/saml2',

    ],

],

'SingleLogoutService' => [

    [

        'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',

        'Location' => 'IDP.azure.com/saml2',

    ],

],

'ArtifactResolutionService' => [],

'NameIDFormats' => [],

'keys' => [

    [

        'encryption' => false,

        'signing' => true,

        'type' => 'X509Certificate',

        'X509Certificate' => 'MIIC8DCCAdigAwIBAgIQZ1u8DdLLcp1LX40zTvYlHjANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yNDAzMjAxNDAzMTRaFw0yNzAzMjAxNDAzMTVaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQgU1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAud9/4Ttvi2sUp8EhIfb9GVKGuGmwr8s59wGPffV7Go6dwVLytRHKu3aeJg',

    ],

],

];

[Tim van Dijen]

Hey Vin,

If you have two SP's, you will also need to register two Enterprise apps in Azure, and you will get two IDP-entries in saml20-idp-remote.php

- Tim

Op woensdag 5 juni 2024 om 09:14:49 UTC+2 schreef jagua...@gmail.com:

[Peter Schober]

Vin Tastic <jagua...@gmail.com> [2024-06-05 09:14 CEST]:

> I’m using different entity id’s and certificates for both sites.

Do you have to use two different entitiyIDs (and key pairs) for the
same SP? Maybe keeping a single entityID (which is abstract in nature
and not tied to a specific deployment/site/host/service URL) for all
vhosts would make this easier.

-peter

[Vin Tastic]

Hi Tim,

I have two enterprise apps setup on Azure side with different certificates for each SP and i have two entries in saml20-idp-remote.php with proper entity id and certificate as mentioned above. Still the test1 always fail when i enable both sites and it works if i comment out the code for test2 in authsources and saml20-idp file.

I haven't setup any session storage or cookie handling settings in my config and I have no idea what could be setup but do you think that could be a reason why both sites are not working simultaneously.

Thanks for your help.

Vin

[Vin Tastic]

Hi Peter,

I do have different entity ids and different self-signed key pairs (i think you mean certificates) for my SPs. The subdomain for the SPs is different so i'm using different entity ids and keypairs. How the setup is currently, it won't be possible to have same  entity id for each SP. i understand you are trying to say that have a site test.example.com and have pages behind it like test.example.com/test1 or test.example.com/test2 but thats not how the setup is done. 

Thanks for the suggestion.

Vin

[Peter Schober]

Vin Tastic <jagua...@gmail.com> [2024-06-06 15:22 CEST]:

> I do have different entity ids and different self-signed key pairs (i think
> you mean certificates) for my SPs. The subdomain for the SPs is different
> so i'm using different entity ids and keypairs. How the setup is currently,
> it won't be possible to have same entity id for each SP. i understand you
> are trying to say that have a site test.example.com and have pages behind
> it like test.example.com/test1 or test.example.com/test2 but thats not how
> the setup is done.

What I am and was saying is that URLs have nothing to do with
entityIDs: You can have one entityID (one logical SP) for many
different URLs and different entityIDs (many logical SPs) for URLs on
the same host.

So the core message was: Unless you know that your SP needs more than
a single entityID sticking with one is simpler.

-peter

[Vin Tastic]

Interesting! Everywhere I have looked, i got the message that the entity id needs to be different. I never thought it's possible to have same entity id for multiple SPs with their own URL.

How do they get differentiated then because in idp-hosted config, i put entity id of the SP  and the certificate that is setup by IDP on AZURE end. 

Could you please provide more details?

Thanks,

Vaneet

[Peter Schober]

Vin Tastic <jagua...@gmail.com> [2024-06-10 20:29 CEST]:

> Interesting! Everywhere I have looked, i got the message that the entity id
> needs to be different. I never thought it's possible to have same entity id
> for multiple SPs with their own URL.
> How do they get differentiated then because in idp-hosted config, i put
> entity id of the SP and the certificate that is setup by IDP on AZURE end.

Well, this wasn't meant as a generic "get out of jail^H^H^H^H managing
multiple SPs for free" card. Just that in certain deployments it makes
sense to have one entityID spread across multiple systems or vice
versa.

One entityID normally means one EntityDescriptor (though nothing's
stopping you from giving out different EntityDescriptors to different
recipients each containing the same entityID; I just find this
needlessly complex) meaning that one EntityDescriptor would contain
all the metadata covering your multiple SP systems, esp. keys and
protocol endpoints.

For *keys* you could list the certificates from multiple key pairs
(i.e., let each "physical" SP instance have its own key pair) or -- if
policy and common sense allow for that -- maybe share the same key
pair across multiple instances.

EntityDescriptor
SPSSODescriptor
KeyDescriptor
KeyDescriptor
KeyDescriptor
etc.

For *protocol* *endpoints* you'd simply list the union of each SP's
ACS URLs in a single EntityDescriptor. Assuming no IDP involved has
the bug of insisting on ACSbyIndex you'd then simply ensure that each
ACS URL has its own, unique index (e.g. by simply enumerating them
starting from 0 or 1).

EntityDescriptor
SPSSODescriptor
AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://host1.example.org/acs/post" index="1"
AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://host2.example.org/acs/post" index="2"
AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://example.com/acs/post" index="3"
etc.

(Note that this does not work with all types of protocol endpoints an
SP might have, only with "indexed" ones, which does include the single
most important one needed for SSO, the ACS URL.
Specifically you can only have a single SLO endpoint for any given
protocol binding, so a logical SP spread across several hosts will
only ever recieve SLO protocol messages at a single endpoint/hostname.
In other words: If you're deployment depends on working SAML SLO you
can't use this method, then.)

I sometimes use such methods when multiple SP instances are
sufficiently close and/or tied together somehow (by common deployment
practices, secrets management, policies, risk assessment) that it
makes no sense to keep the SAML config different. E.g. prod and QA and
testing instances of some piece of software are not QA'ing or testing
the SAML SSO portion of the system but the application code itself.
I might use a logical SP for all these instances, then. But maybe not
for dev instances, e.g. when different instances might also have
access to different data sets (e.g. mock/minted test data).
YMMV.

HTH,
-peter