two domains on same nginx using same SP simplesaml set up for same remote IDP
729 views
Skip to first unread message
Tommy Peterson
Mar 20, 2016, 3:52:26 PM3/20/16
to SimpleSAMLphp
I have one web applications that acts as an SP to a remote ADFS IDP. The SP uses a simplesamlphp install on a Linux server using Nginx. I will call it app1.mycompany.com
I want to add another web application to the same LInux server and vhost Nginx set up that connects to the exact same remotely installed/served ADFS IDP. It is app2.mycompany.com
I wanted to avoid installing another simplesamlphp build for the second SP. So I just added a second SP configuration in the config/authsources.php file that the first app is set up in. Again, both are SP's. However, when I click on log in, the log in gets correctly routed to the IDP, I enter my credentials, but the IDP reports an error giving a reference number. The first application's SSO to the IDP still works fine.
I do not control the IDP or have access to its server. So I am surmising that this is because both SP's report the same endpoints--same domains--the original one.
Do I need to do something like is described in here:
https://groups.google.com/forum/#!search/multple$20domains$20for$20single$20installation/simplesamlphp/uXNpvWd_XS8/AvAkT01swPgJ
If so, which method/approach?
Right now application 1 (the original one) Is the one aliased to simplesaml. You can get the simplesaml admin page by going to app1.mycompany.com/simplesaml/ But you cannot get the simpelsaml admin page from the second app at all, not even app2.mycompany.com/simplesaml/ because I didnt' modify the vhost file on the sp server.
Should I? Is this necessary? Before I affect users by a web server restart I wanted to ask.
But both of the apps show up in the simplesaml admin page federation test login tab.
Also, each SP configuration in the authsources.php file has its own unique entityID. I saw in the forum post I pasted above someone used "NULL" or something and people were referencing using PHP's $_SERVER, which I don't get. The point to the saml IDP entityID configured in the metadata idp file.
The IDP shows metadata for both applications as having endpoints as app1.mycompany.com . . . in the strings. For examples, both the existing SP and the new one I added show the following on the IDP:
https://app1.mycompany.com/simplesaml/module.php/saml/sp/saml2-acs.php/app1-adfs-idp
whereas I would think the new one would have to be
https://app2.mycompany.com/simplesaml/module.php/saml/sp/saml2-acs.php/app1-adfs-idp
By the way, if it is not clear, both of these apps are not only on the same linux server, same nginx, but they also have the same domain, just different subdomains.
What else am I missing in this set up? What else do I need to do? Or should I just install another simplesamlphp for the new application?
Also, I don't think I need to modify the sessions do I? Since they are the same domain but different subdomains. I had two different apps installed on one server using one web server but had different domains. I had to use MySQL for the sessions to avoid session collisions/drops.
Thanks.
I want to add another web application to the same LInux server and vhost Nginx set up that connects to the exact same remotely installed/served ADFS IDP. It is app2.mycompany.com
I wanted to avoid installing another simplesamlphp build for the second SP. So I just added a second SP configuration in the config/authsources.php file that the first app is set up in. Again, both are SP's. However, when I click on log in, the log in gets correctly routed to the IDP, I enter my credentials, but the IDP reports an error giving a reference number. The first application's SSO to the IDP still works fine.
I do not control the IDP or have access to its server. So I am surmising that this is because both SP's report the same endpoints--same domains--the original one.
Do I need to do something like is described in here:
https://groups.google.com/forum/#!search/multple$20domains$20for$20single$20installation/simplesamlphp/uXNpvWd_XS8/AvAkT01swPgJ
If so, which method/approach?
Right now application 1 (the original one) Is the one aliased to simplesaml. You can get the simplesaml admin page by going to app1.mycompany.com/simplesaml/ But you cannot get the simpelsaml admin page from the second app at all, not even app2.mycompany.com/simplesaml/ because I didnt' modify the vhost file on the sp server.
Should I? Is this necessary? Before I affect users by a web server restart I wanted to ask.
But both of the apps show up in the simplesaml admin page federation test login tab.
Also, each SP configuration in the authsources.php file has its own unique entityID. I saw in the forum post I pasted above someone used "NULL" or something and people were referencing using PHP's $_SERVER, which I don't get. The point to the saml IDP entityID configured in the metadata idp file.
The IDP shows metadata for both applications as having endpoints as app1.mycompany.com . . . in the strings. For examples, both the existing SP and the new one I added show the following on the IDP:
https://app1.mycompany.com/simplesaml/module.php/saml/sp/saml2-acs.php/app1-adfs-idp
whereas I would think the new one would have to be
https://app2.mycompany.com/simplesaml/module.php/saml/sp/saml2-acs.php/app1-adfs-idp
By the way, if it is not clear, both of these apps are not only on the same linux server, same nginx, but they also have the same domain, just different subdomains.
What else am I missing in this set up? What else do I need to do? Or should I just install another simplesamlphp for the new application?
Also, I don't think I need to modify the sessions do I? Since they are the same domain but different subdomains. I had two different apps installed on one server using one web server but had different domains. I had to use MySQL for the sessions to avoid session collisions/drops.
Thanks.
Patrick Radtke
Mar 21, 2016, 5:08:37 PM3/21/16
to SimpleSAMLphp
The SP metadata generation takes into account the hostname you connect on.
You'll want to download you app1 metadata from
and your app2 metadata from
I believe one of your problems is that you downloaded both SP's metadata from the app1 url and the URLs in that metadata then all reference the app1 domain.
The last path component in those URLs must be the key for those SP in your authSources.
To make your 2nd SP functional you'll need to have your VHOST config for app2 aliased for /simplesaml.
hope that helps,
-Patrick
Nate Klingenstein
Mar 21, 2016, 6:01:03 PM3/21/16
to simple...@googlegroups.com
One other NB to add to Patrick’s answer. An “application” in the context of SAML can span multiple different hosts, or a single host can have multiple distinct applications.
You can place metadata for multiple services in a single entry, even with multiple domains. You will need to do the merger by hand, since as Patrick mentions, simpleSAMLphp is reliant on introspection of the environment it’s running in to generate this for you. It wouldn’t be able to tell that it’s running on different domains as the same thing.
Whether you want this to be a separate service or not is a deployment question. I’ll use an academic library as an example. Is the right granularity, “the service to check out books” and “the digital archival service”, “all the applications at the library”, or “all the community member facing services at the university”? It’s an art rather than a science.
If you pick a coarse grain, the IdP does not need to know these distinctions and generally can’t make the distinctions even if they wanted to do so, but management of all these connections gets much easier.
You can place metadata for multiple services in a single entry, even with multiple domains. You will need to do the merger by hand, since as Patrick mentions, simpleSAMLphp is reliant on introspection of the environment it’s running in to generate this for you. It wouldn’t be able to tell that it’s running on different domains as the same thing.
Whether you want this to be a separate service or not is a deployment question. I’ll use an academic library as an example. Is the right granularity, “the service to check out books” and “the digital archival service”, “all the applications at the library”, or “all the community member facing services at the university”? It’s an art rather than a science.
If you pick a coarse grain, the IdP does not need to know these distinctions and generally can’t make the distinctions even if they wanted to do so, but management of all these connections gets much easier.
Tommy Peterson
Mar 23, 2016, 10:23:27 AM3/23/16
to SimpleSAMLphp
Yes. The problem was indeed that the second app needed to have an alias for the simplesamlphp directory, just like the first app. Even though going to app1.mycompany.com/simplesamlphp will give the url for BOTH SP's listed on the federation tab in the metadata and so too will going to app2.mycompany.com/simplesamlphp you just have to know which application's metadata you need to give the IDP folks and use that URL. So go to app1.mycompany.com/simplesamlphp to get the metadata URL for that app and send that URL to the IDP folks to configure their end. THen go to app2.mycomapny.com/simplesamlphp to get that metadata URL to send to the IDP folks to configure their end for that SP's SSO. Seems kinda odd. But it works.
Reply all
Reply to author
Forward
0 new messages