multiple sp hosts behind a firewall/proxy etc

[Musil, William]

Thanks Peter.

I read that doc too, but I didn't clearly understand what the metadata represented. I misunderstood the entity. I had the notion that each shib would create an instance and host specific key pair. I didn't understand that it is entity specific, and therefore portable from SP to SP.

We only have shib protecting the entry elements, all other session management in the app is shib-less.

There are occasional reauthorization checks in our application, which would bounce back to shib, but even if I hit a shib where the session was not cached, that is fine, because it would force a relog. This is OK too, as without SSO, these work processes normally require end user confirmation by supplying credentials again any way (e-signature, certain types of data manipulation.) and even with SSO, the audit trail of the application would show the confirmation. Because of this, if the SSO is generally consistent, while occasionally asking for credentials again, the end users would not mind.

I expect that I can ignore or live without shib persistence past the point of a transaction.

The articles mentioned and your explanation have helped me better understand how to get this done.

Thanks.


Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: Peter Schober <peter.schober at univie.ac.at>
Date: 05/23/2015 13:16 (GMT-05:00)
To: Shib Users <users at shibboleth.net>
Subject: Re: multiple sp hosts behind a firewall/proxy etc

* Musil, William <wmusil at labvantage.com> [2015-05-23 15:57]:
> This works perfectly for me if there is one and only one SP resource
> in the backend.

OK.

> I am trying to deal with a cluster of systems each with SP loaded,
> say proxy with backends resource1 and resource2.

That's relevant new information, of course, and changes quite a few
things. Here's the documentation for that:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering

That's also the first result I get when I search for "sp cluster" in
the documentation (search box in the upper right corner).

* Musil, William <wmusil at labvantage.com> [2015-05-23 16:58]:
> I will keep reading. I expect that I can have many copies of sp, all
> running as the same identity, and this is scary to me, at least for
> now.

If all the SP instances should behave as one (i.e., you're clustering)
then you'd configure all SPs with the same key pair and the same
entityID (same everything). Not sure what's scary about that if that's
the expected behaviour.

> Any how-to dealing with implementing a single SP across multiple
> physical sp daemons would be welcome.

The page above explain all of the variants, incl. "shared nothing" and
relying on a clustered application session alone (which you seem to
have disregarded, from all the options you have).
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150523/0dd71ebf/attachment.html>