SP Sessions across multiple user facing server tiers

[Alexander F. French]

I will be very verbose, and hopefully in that verbosity will be clear:

I have a solution that is a combination of packaged software, homegrown apps, and packaged software talking to homegrown apps.  Conceptually, I believe it makes sense to think of it all as one "application" in Shibboleth's terms.

---
Vendor historical recommendation
---
Is two separate tiers, because this was a good starting point for performance and security options... oh, 15 years ago:

	product-foo.myorganization\foo		<-- user facing vendor app
	product-bar.myorganizattion\bar		<-- also user facing vendor app

---
Our state for the last few years
---
We've run multiple load-balanced servers in each tier, with the load-balancer routing traffic to the appropriate tier based URL information other than the host name:

	Product.myorganization\foo			<-- routes to the Foo tier
	Product.myorganization\bar			<-- routes to the Bar tier

One key is that the unified hostname lets the Foo packaged app talk to web services running on the Bar tier without any cross-origin concerns.  With the implementation details of our previous SSO integration product, this worked fine.

---
Where I'm at:
---
With the Shibboleth SP on my IIS servers, I can make this work pretty smoothly- the metadata I've provided to the Idp includes both of these endpoints:
	\foo\Shibboleth.sso
	\bar\Shibboleth.sso

The config file on the Foo tier and the Bar tier have the endpoints setup respectively, my load-balancing logic smoothly handles redirects from the IdP to the desired tier.

UNTIL- the user tries to connect to both the Foo tier and the Bar tier, particularly by connecting to the Foo tier and then in-browser talking to web services on the Bar tier.

Now, (just one example) the user's browser connects to the Foo tier and creates a Shibboleth session happily.  But when it tries to connect to the Bar tier it is unsuccessful (the web service call is redirected to the IdP, the browser cries cross-origin problem, and even if the browser allowed the redirect to the IdP and back I would lose POST data in some cases).  And then the next connection to the Foo tier is also unsuccessful, because the browser lost its Shib session cookie when it failed to connect to the Bar tier.

---
What I probably should do
---
I'm pretty sure that the right answer, and a feasible answer is just to move away from the default vendor recommendation and combine the Foo and Bar tiers.  These are not just two physical servers behind a simple network firewall, I can still manage access control in detail at the load-balancer level and I can scale the combined FooBar tier horizontally.  This also simplifies sys admins managing VMs and simplifies the load-balancer configuration, but it is a change.

---
Other ideas?
---
Before I do that, I want to make sure I'm aware of Shibboleth options that would facilitate the current two-tier state.

It looks to me like the multiple-tiers-behind-one-host-name-and-inside-one-Shibboleth-application is just a special case of clustering in general, as far as SP is concerned.  The options are documented in NativeSPClustering page in the wiki.
	-Shared process would introduce a little new complexity and create dependencies.  Sharing a process in between one Foo and one Bar server, but not across the full horizontal spread of each tier, would be complicated or impossible to make work at the load-balancing level.  Sharing a single process across all servers would create a new single point of failure.

	-Shared database would require a lot of new complexity.  We do have clustered databases available that would could probably make this robust, but... the wiki seems pretty clear that this isn't a go-to, well supported and tested option that is endorsed by anyone.

I appreciate any feedback *including*:
	- "This sounds stupidly complicate, you should make it simpler" 
		(you are correct)
	- "The Shibboleth SP does not support that well"
		 (good, I was pretty sure)
	- "Here are some options that are applicable here are some options that seem applicable but won't help"
		(good, now that I know I should just make my environment simpler)		

Thanks,
Alex French