Single Sign On
UF Single Sign On (SSO)
University of Florida leverages Shibboleth as the Identity Provider (IdP) for single sign on (SSO). UF's implementation supports SAML2 and OpenID Connect (OIDC) protocols.
There are 2 main components for UF SSO:
- Identity Provider (IdP): This component is responsible for authenticating users and providing identity information to a Service Provider (SP). This is managed by the UFIT Identity & Access Management (IAM) team.
- Service Provider (SP): This component is responsible for triggering the authentication and sits at the resource (i.e. website, application). This is managed by the resource's administrator such as an application administrator, webmaster, etc.
UF SSO Simplified Operational Diagram
The figure below shows basic Shibboleth data flow beginning with a user requesting service from a Service Provider (SP) such as a UF website. Using Shibboleth, the Service Provider (SP) does not request the user name and password. This is done by the Identity Provider (IdP) login.ufl.edu.
One of the advantages of implementing SSO is the SP does not hold or manage passwords. Additionally, central policies to mitigate risks associated with GatorLinks are applied every time they are used to ensure a safe and secure authentication process including multi-factor authentication (MFA).
Each application/website is considered a Service Provider (SP) which is owned and managed by the application/website administrator. The UFIT IAM team does not manage services providers nor is it responsible for updating their respective metadata and associated certificates.
SP Request Process
All SPs are expected to follow the UF SP policies given on the policies page: https://identity.it.ufl.edu/technical/gatorlink-authentication-setup-request/uf-sp-policies/.
The steps for requesting a new SP are:
- All new SPs (except for WordPress sites) are required to have an up-to-date risk assessment of your application. Please go to the Risk Assessment page to begin. The Risk Assessment number will needed before an SP can be requested, and the SP will not be approved before the assessment is complete. The Risk Assessment can be found at this link : Risk Assessment.
- The SP can be requested on the SP Registry site. Note that requestor must be one of the technical or security contacts for the SP.
- Log into the SP Registry
- Click “Request New SP Group”
- The information required for an SP request is documented in the SP registry.
- If you are unsure of what any of the fields mean, hold the mouse over the label (the left column of the online form) and a description of the data will appear.
- The requestor should ensure departmental awareness of the request.
- The requestor, as well as the other contacts, should be aware that they will be required to recertify the SP (i.e. verify all contact information) on an annual basis.
- The IAM Team will review the request and work with the requesting department and campus-at-large and will make any needed changes or adjustments to the request.
- The request is accepted or denied.
- The request is implemented as approved. Technical staff will communicate and establish the new service.
Note: Most areas need to consider how testing will be done and if they need a test service included. This is a preferred and recommended practice. In some large enterprise areas multiple test and development areas might need to be established for the service provider (SP) to deploy applications. The SP should be requested/configured with multiple entityID identifiers for application testing environment as needed.
If you want a visual of all the steps required, you can download the UF Service Provider Request Workflow Diagram.
Shibboleth and Windows Server
This page describes the steps necessary to install the Shibboleth SP component on a Windows Server. The steps have been tested on a Windows Server 2022 Datacenter edition.
Requirements
- Shibboleth SP installation file
- Windows Server
- Certificate bound to 443/tcp for HTTPS communication
- Download the Shibboleth SP for Windows (https://shibboleth.net/downloads/service-provider/latest/win64/).
- Run the installation file as administrator
- Click on Next
- Accept the terms in the license agreement and click Next
- Keep the default URL and check the Configure IIS support checkbox. Click Next
- Click Install
- Once the installation is finished, click on Finish
- Restart your server by clicking on Yes
- Once your server is back online, open a browser and browse to https://localhost/Shibboleth.sso/Metadata
- You should be able to download metadata. Another URL you can browse to is https://localhost/Shibboleth.sso/Session. It should return the following message: A valid session was not found
Apache .htaccess
Please note that authorization may fail in these examples should you restrict access based on attributes your service provider is not receiving. Also, if you choose to use regular expressions, please pay close attention to substring matches and multivalued attributes. You may use regex lines like require UFAD_Groups ~ "(^|;)Group1($|;)" to ensure you only match an explicit value in a multivalued attribute.
AuthType shibboleth ShibRequireSession on require valid-user
AuthType shibboleth ShibRequireSession on require mail alberta@ufl.edu
username AuthType shibboleth ShibRequireSession on require glid alberta
AuthType shibboleth ShibRequireSession on require UFAD_Groups Group1 require UFAD_Groups Group2
AuthType shibboleth ShibRequireSession on require UFAD_Groups Group1 Group2
AuthType shibboleth ShibRequireSession on require primary-affiliation ~ STAFF|FACULTY
AuthType shibboleth ShibRequireSession Off require shibboleth
Instructions for Installing the Shibboleth Module on Redhat Linux
Prerequisites
- Redhat 4 or 5
- Apache Installed
- Download the RPMs for RedHat, do the following. You may need to change the RedHat version and architecture.
curl -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/log4shib-1.0.3-2.1.i386.rpm \ -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/opensaml-2.3-1.6.i386.rpm \ -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/shibboleth-2.3.1-1.2.i386.rpm \ -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/xerces-c-3.0.1-6.1.i386.rpm \ -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/xml-security-c-1.5.1-4.1.i386.rpm \ -O http://ftp5.gwdg.de/pub/opensuse/repositories/security:/shibboleth/RHEL_4/i386/xmltooling-1.3.1-1.2.i386.rpm
- Install the RPMs with the following command:
rpm -ivh log4shib-1.0-1.i386.rpm \ xerces-c-2.8.0-1.i386.rpm \ xml-security-c-1.4.0-1.i386.rpm \ xmltooling-1.0-6.i386.rpm \ opensaml-2.0-6.i386.rpm \ shibboleth-2.0-6.i386.rpm
- Edit your httpd.conf to Include mod_shib support:
Include /etc/httpd/conf.d/shib.conf
- Edit your httpd.conf for apache turning on UseCanonicalName. If this is not done weird errors will occur.
- Restart Apache
- Start up shibd:
/sbin/service shibd start
Protecting Content
Access control in Shibboleth on Apache is done by either modifying the shibboleth2.xml file in /etc/shibboleth or in the main httpd.conf file or in an .htaccess file. Find more information about protecting content in Shibboleth's documentation.
Access control rules allow you to use boolean logic to specify if a web resource is accessible based on what attributes are available. One of the attributes in our environment that is used in access control is “primary-affiliation”. It specifies if the user accessing the resource is either a “Staff”, “Student”, or “Guest”. For example, a rule to allow only “Staff” to access a resource the rule would look like this:
<AccessControl> <Rule require="primary-affiliation"<STAFF>/Rule<</AccessControl>
To protect content if the user is either a “Staff” or “Student” you would use this rule:
<AccessControl> <OR> <Rule require="primary-affiliation">STAFF</Rule> <Rule require="primary-affiliation">STUDENT</Rule> </OR> </AccessControl>
- Open up the shibboleth2.xml file located in
- Look for a <RequestMapper>element in the shibboleth2.xml file. There should be a child element named <Host>that has an attribute named “name” that is your website’s name
- There should be a child element of <Host> named <Path> that has an attribute named “name” which corresponds with a url in your website that you want protected. By default, that name is “secure”. Change the name to be a part of your webspace that you want to protect eg if you want to protect http://hostname.ufl.edu/payroll then the name attribute would be “payroll”
- Create a child element of <Path> named <AccessControl> which follows the syntax in the above section.
- Restart the shibboleth daemon
Using Apache’s native access controls is really simple and intuitive to do with Shibboleth. If you wish to make content available to any valid user the following could be placed in either an .htaccess file or your webserver config:
AuthType shibboleth ShibRequireSession On require valid-user
If you wanted to only allow authenticated users that are staff members, do the following:
require primary-affiliation STAFF
If you want to give access to either staff or faculty, the following can be used:
require primary-affiliation ~ STAFF|FACULTY