Setup Shibboleth Server on Azure/AWS/GCP
Setup and install Shibboleth on Rocky Linux 9 in Azure, AWS or Google GCP. Use our image from any of the cloud marketplaces below to deploy Shibboleth with Apache. Our Federated Identity Gateway solution provides a secure, scalable using Shibboleth for managing Single Sign-On (SSO) and federated identity within enterprise environments. Optimized for deployments in the cloud, this solution empowers organizations to streamline access to protected resources and centralize user authentication.
Single Sign On and Federated Identity with Shibboleth
Shibboleth Azure
Deploy Shibboleth on Rocky Linux 9 in Azure
Shibboleth AWS
Coming Soon..
Shibboleth GCP
Coming Soon..
Getting Started with SSO and Federated Identity using Shibboleth
Once your Shibboleth server has been deployed, the following links explain how to connect to a Linux VM:
- How to connect to a Linux VM on Azure
- How to connect to a Linux VM on AWS
- How to connect to a Linux VM on GCP
Once connected and logged in, you’re now ready to start using your new Shibboleth server.
Step 1. Verify Shibboleth Service Status
Check Apache and Shibboleth Daemon: Ensure both Apache and the Shibboleth daemon are running:
sudo systemctl status httpd
sudo systemctl status shibd
If either service is not running, start them:
sudo systemctl start httpd
sudo systemctl start shibd
Step 2. Test Shibboleth Configuration
Run Shibboleth Configuration Check: Confirm that the Shibboleth configuration loads successfully:
sudo shibd -t
This command should output overall configuration is loadable. If there are any errors, users should review the configuration and address any noted issues.
Test Apache Configuration:
sudo apachectl configtest
This command should output Syntax OK. If any errors are shown, users may need to correct the Apache configuration.
Step 3. Access the Shibboleth Status Page
Check the Shibboleth Status:
- Access the Shibboleth status page through a web browser to verify the Shibboleth Service Provider (SP) module is loaded:
https://<server-ip-or-domain>/Shibboleth.sso/Session
Ignore the certificate warning and proceed. The page should confirm the status, indicating a “valid session was not found,” which confirms Shibboleth is communicating with Apache and is active.
Step 4. Configure Identity Provider (IdP) Information
Update shibboleth2.xml for Your IdP:
- Open
/etc/shibboleth/shibboleth2.xmland update the following attributes based on your organization’s IdP:- entityID: Change this to the EntityID from your IdP.
- SSO: Ensure the URL points to your IdP’s login endpoint.
Detailed steps are on https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335529/GettingStarted
sudo nano /etc/shibboleth/shibboleth2.xml
Save changes and exit, then restart services to apply the changes:
sudo systemctl restart httpd
sudo systemctl restart shibd
Step 5. Secure Shibboleth Logs and Monitor Activity
- Shibboleth logs are stored in
/var/log/shibboleth/shibd.logby default. - Regularly monitor logs to identify any unusual activity or issues with authentication
sudo tail -f /var/log/shibboleth/shibd.log
Step 6. Register Service Provider with IdP
For your Service Provider (SP) to authenticate with an external IdP, you’ll need to share metadata with your IdP administrator. The metadata URL can typically be accessed at:
https://<server-ip-or-domain>/Shibboleth.sso/Metadata
Ensure your IdP admin registers this metadata in the IdP configuration.
If you receive an error Metadata Request Failed, SELinux could still be restricting access based on hostname or IP access. To rule it out, set SELinux temporarily to permissive mode and retry:
sudo setenforce 0
Then retry again via your browser:
https://<server-ip-or-domain>/Shibboleth.sso/Metadata
Documentation / Support
The above guide provides a comprehensive overview for post-deployment steps, including verification, customization, and security recommendations. For additional details on configuration, users can refer to Shibboleth’s official documentation.
Server Logs
Check Shibboleth’s log files for more specific error messages if you’re encountering issues:
/var/log/shibboleth/shibd.log/var/log/httpd/error_log
Firewall Ports
Shibboleth primarily operates as a web-based identity solution and relies on the same ports as web servers for secure communication and data exchange. The key ports are:
Port 443 (HTTPS):
- This is the primary port Shibboleth uses for secure communication between the Service Provider (SP), Identity Provider (IdP), and users. All SAML assertions and authentication responses are typically sent over HTTPS for security.
Port 80 (HTTP):
- Though most communication occurs over HTTPS, HTTP (port 80) may be used for initial redirects before being upgraded to HTTPS, as well as for certain non-sensitive requests.
Apache and Web Server Configuration:
- Shibboleth is often integrated with web servers like Apache or Nginx, so it will use whatever ports are configured on those servers (typically 80 and 443).
Optional Administrative Port:
- If an administrator chooses to configure a Shibboleth status or administrative endpoint, it may require a separate port, though this is not commonly enabled on production systems.
Additional configurations or specific federation requirements may lead to the use of custom ports for administrative or internal access, depending on your network setup and security requirements.
The links below explain how to modify / create firewall rules depending on which cloud platform you are using.
To setup AWS firewall rules refer to – AWS Security Groups
To setup Azure firewall rules refer to – Azure Network Security Groups
To setup Google GCP firewall rules refer to – Creating GCP Firewalls
Disclaimer: Shibboleth is a registered trademark of Internet2 and is licensed under Apache License 2.0. This image is provided & maintained by Cloud Infrastructure Services. This solution is not affiliated with or endorsed by Shibboleth or Internet2. No warrantee of any kind, express or implied, is included with this software. Use at your risk, responsibility for damages (if any) to anyone resulting from the use of this software rest entirely with the user. The author is not responsible for any damage that its use could cause.
