Changes between Version 4 and Version 5 of IdpOverview

Timestamp:

07/08/11 14:55:19 (13 years ago)

Author:

jpmitchell@…

Comment:

--

IdpOverview

@@ -9 +9 @@
 The Shibboleth implementation runs in a Java web container. The UA installation is running on Tomcat 6.x support by Java 1.6. It is installed in the /opt/shibboleth-idp and /opt/tomcat directories. We are not using the Red Hat supplied Tomcat as it is currently only at version 5.x for RHEL 5.x which is the supporting OS.
 
-Load balancing is performed via a set of hardware appliances built by Coyote Point configured in a master/slave redundant pair. The https://idp.alaska.edu service URL is bound to the load balancer which utilizes some form of NAT to rewrite packets and send them to the servers that are actually running the Shibboleth service. Currently the load balancer is providing fail over for the two production boxes in a master/hot-standby configuration. This is due to the nature of sessions in SAML and how state is managed in Shibboleth. Currently if one production server goes down the load balancer will shift load to the other production server and SSO sessions are lost for users. Current application sessions (SPs) are maintained in the applications, so users can still access current applications but will be forced to login again to new applications.
+Iptables is used to re-write packets arriving on the virtual hosts on port 443 to port 8444. This is so the Tomcat server can run without root on the virtual host.
+
+Load balancing is performed via a set of hardware appliances built by Coyote Point configured in a master/hot-standby redundant pair. The https://idp.alaska.edu service URL is bound to the load balancer which utilizes some form of NAT to rewrite packets and send them to the servers that are actually running the Shibboleth service. Currently the load balancer is providing fail over for the two production boxes in a master/hot-standby configuration. This is due to the nature of sessions in SAML and how state is managed in Shibboleth. Currently if one production server goes down the load balancer will shift load to the other production server and SSO sessions are lost for users. Current application sessions (SPs) are maintained in the applications, so users can still access current applications but will be forced to login again to new applications.
 
 References:[[br]]