multiple sp hosts behind a firewall/proxy etc

[Musil, William]

Thanks Scott.

I think from reading and Peter's explanation, I will likely not even try to use database persistence. Our application does not require SSO and doesn't use shib for any session data, save for the credential transaction, so having multiple SP with an identical entity should do fine by me. Our effort is focused on integrating our application into an existing federated shibboleth environment that is already in use, as well as ensuring that we have a documented implementation process  for other future mplementations that also require shibboleth. I only need the shib session for the app to SP to idp to SP to app transaction flow. Once the credential phase is complete our session management takes over.

I didn't understand the concept of logical SP and that the entity was completely abstract. I assumed incorrectly that they keying was at least partially host specific. Knowing that it is not makes it clearer to me what I need to do.

Thanks again.


Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: "Cantor, Scott" <cantor.2 at osu.edu>
Date: 05/23/2015 18:18 (GMT-05:00)
To: Shib Users <users at shibboleth.net>
Subject: Re: multiple sp hosts behind a firewall/proxy etc

On 5/23/15, 11:47 AM, "Musil, William" <wmusil at labvantage.com> wrote:

>The issue I think would be that session state at shibd is not shared

If you've solved the brutally difficult problem of how to cluster an application, then you should try and avoid any use of the SP session other than to initially create an application session and by all means do *not* waste your time trying to cluster the SP.

The clustering material in the wiki takes great pains to say this.

>It is almost like what I really need is to put SP deeper into the application layer itself like if SP was a clusterable container, and shibd actually ran as a servlet, using the session replication that comes with java application servers and cluster aware java web applications to store the shibd sessions state data.

Then don't use Shibboleth and find a Java SP you can live with. The Shibboleth SP is not designed to run inside applications and it never will be. It's about an entirely different problem space.

>I don't know how to do it yet, but if I persist in a database, I might be able to pull this off.

On Windows, ODBC is reasonably reliable and not a terrible option with the SP. On Linux it's often unreliable because of bad drivers and ODBC libraries, and it's very system dependent how well it works.

-- Scott

--
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/31cf3b2c/attachment.html>