You MUST NOT continue to installation until you’ve worked through the checklists below. Environmental preparation is critical to a successful outcome.
These requirements apply to both new installations and upgrades from version 3 of Shibboleth
TABLE OF CONTENTS
- Required Checklist
A dedicated CentOS 7, 8 or Stream or RedHAT 7 or 8 or Ubuntu 20.04 (virtual or physical), with the following minimum specifications:
- 2 CPU
- 4GB RAM
- 10GB+ partition for OS
The AAF recommends CentOS Stream only be used in the AAF Test environment, NOT as a production.
Access to additional software repositories are required to provide software such as Ansible. For CentOS the Extra Packages for Enterprise Linux (EPEL) are required. Please refer to the Fedora Wiki - EPEL for additional information.
The following repositories will be required for RedHAT servers
- You MUST have SSH access to the server
- You MUST be able to execute commands as
rooton the system without limitation
- The server MUST be routable from the public internet with a static IP. Often this means configuring the IP on a local network interface directly but advanced environments may handle this differently.
- The static IP MUST have a publicly resolvable DNS entry. Typically of the form
The server MUST be able to communicate with the wider internet without blockage due to firewall rules. All publicly routable servers MUST be accessible for:
|80||Outbound HTTP connections|
|443||Outbound HTTPS connections|
Each of the following commands MUST succeed when run on your server:
If direct access is not available, a web proxy will be required! This will allow the installer to access required content on the Internet.
If direct access is not available, then prior to running the Installer and deploy scripts you MUST set the following environment variable; Additional configuration within the IdP will also be required to use the web proxy.
The server MUST be accessible from the wider internet without blockage due to firewall rules for:
|443||Inbound HTTPS connections used within SAML flows|
(Optional, not recommended)
|Backchannel, client verified TLS connections, used within SAML flows.|
Only required if the Back-Channel is enabled.
The AAF recommends that the back channel NOT be enable as there are no federation services that require it. Only if you have local services attached to your IdP that require access to the IdP back channel, should you then enable it.
See Shibboleth Wiki - Security and Networking - Back-Channel Support for more details.
Please refer to the Advanced IdPv4 configuration section If you have is a load balancer or similar between your IdP and the Internet.
Environmental data for your IdP
The following information is required by the AAF IdP Installer and must be populated into the bootstrap-v4.ini file prior to running the installer. For migrations from version 3 a script has been provided to create and populate a bootstrap-v4.ini file that can be used in the migration process. See using the IdPv3 export-config script for more details.
|Host Name||The public domain name of the IdP. May be used in determined the entityID of the IdP.|
|Entity ID||The unique technical name of the IdP. If migrating from an older IdP then its entity id should be used on the new IdP.|
A determination of the AAF federation you wish to register your IdP within, being test or production. AAF Support can assist you in determining this
|Organisation Name||The human readable display name of your organisation|
|Organisation base domain||e.g. example.edu, used for the scope of user's scoped attributes|
|Install base||Where in the file system you want the IdP to be installed. The default is /opt|
|Patch System Software||If enabled, the operating system software will be updated every time the IdP is deployed, that is the command "yum update -y" will be executed. If you have your own system patching regime in place you can disable this feature.|
Default is enabled.
|eduGAIN enabled||Additional configuration is enabled to allow the IdP to technically connect to eduGAIN. See AAF eduGAIN for more information and how to join eduGAIN.|
Default is NOT enabled.
|Local firewall enabled||If enabled, firewalld will be enabled and configured on the server allowing.|
Default is enabled.
|Back-Channel enabled||If enabled, the IdP will support back-channel requests.|
Default is NOT enabled.
LDAP connection information
If your IdP connects to an LDAP directory or Active Directory server for authentication and attribute resolution you will need to gather the following information. This information is provided using the bootstrap-v4.ini file in the [ldap] section.
The AAF IdP installer only supports connection to one LDAP server. Shibboleth can support multiple LDAP servers as well as other sources of authentication and attributes, including another SAML or OIDC IdP. You’ll need to undertake further customisation during the installation process when prompted. Each of these scenarios are currently outside of the installers scope.
LDAP URL the Shibboleth IdP will connect to. The URL can only contain the scheme, address, and port. If a secure (recommended) connection is being make to the LDAP server additional configuration will be required.
|LDAP_BASE_DN||Point from where LDAP will search for users|
|LDAP_BIND_DN||The administrator's bind dn|
|LDAP_BIND_DN_PASSWORD||The administrator's password|
|LDAP_USER_FILTER_ATTRIBUTE||Generally use uid for most LDAP servers and sAMAccountName for MS Active Directory. In some situations the directory will use cn (commonName) to hold the users unique login name.|
If your LDAP connection is over LDAPS or startTLS you will need the root and intermediate certificates that make up the certificate chain to the LDAP certificate the protects the LDAP endpoint.
For all new installs and migrations from version 3, once you’ve finalised these checklists please continue to the installation stage.