| | 2 | |
| | 3 | This page describes the installation of the Shibboleth/SAML IdP in a general way to orient technical individuals. |
| | 4 | |
| | 5 | Currently there is three Shibboleth [[https://iam.alaska.edu/projects/wiki/IamProjectHosts|servers]] in the IAM infrastructure. One is used for testing, development, and Q&A kinds of operations. Two are used for serving production load in a master/hot-standby configuration. Generally change to the system should flow through test to the hot-standby and then to the master depending on the nature of the change and risk of service interruption. |
| | 6 | |
| | 7 | Each of the servers is a virtual host. The virtual hosts are running in the UA VMware farm. Each virtual host is guaranteed to not be running on the same physical host to provide redundancy. Each of the servers is running local storage for the application. |
| | 8 | |
| | 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. |
| | 10 | |
| | 11 | Load balancing is performed via a hardware appliance built by Coyote Point. 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. |
