Authentication for Web Based Services – Setup Request

This procedure is for UF departments to request the establishment of a Service Provider that can use a Shibboleth-based UF GatorLink Authentication service via login.ufl.edu. UF GatorLink Authentication allows for Web-based and non Web-based applications to accept GatorLink credentials. The following procedures are required for adding, removing, updating, or recertifying an attribute release policy in the UF Authentication system. Questions should be directed to the Identity and Access Management (IAM) Team.

SP Policies

All SPs are expected to follow 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:

  1. 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.
  2. 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.
  3. The requestor should ensure departmental awareness of the request.
  4. 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.
  5. 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.
  6. The request is accepted or denied.
  7. 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.

SSO on vendor provided SPs

When working with a vendor to set up SSO for an SP that they provide, the following notes should be helpful.
  1. Per UFIT standards, all Vendor SPs must use Gatorlink SSO for authentication. SAML2 (an industry standard) is our preferred method for SSO. Ensure that the vendor supports SAML2 SSO authentication. If the vendor does not support SAML2, we have the fallback option to support OIDC (another industry standard).
  2. Always get a document from the vendor describing their process for setting up either SAML2, or if necessary, OIDC SSO authentication.
  3. Engage IAM (either using a Cherwell ticket or by email). IAM will need to be involved in all vendor SAML2/OIDC integrations. When engaging IAM, include the documentation obtained from the vendor. We will not be able to assist until we have that documentation.
Information we will require from the vendor (which should be included in the documentation they provide) are:
  1. The entityID of the SP
  2. A list of attributes/claims that the SP will need from the IdP.
  3. Vendor contact information (that will be included in the SP registry form.
Additional notes:
  1. If possible, complete the SP registry request before engaging IAM.  If that is not possible, due to not understanding the requirements of the SP, or not all information available, go ahead and engage IAM rather than delaying things.
  2. For SAML2 implementations, all SPs are required to support signed SAML2 transactions. Some vendors do not support the use of signing certificates, and these will require approval from UFIT management (and possibly the security office) to permit them to use our SSO. Exceptions are temporary, and not all data will be made available to SPs that do not support signing.
  3. For SAML2 implementations, Vendors should have the ability to provide SAML2 SP metadata. This is typically the case, but in some instances, they do not provide metadata. Creating metadata manually is tricky and time consuming and will need IAM approval.
  4. It would be convenient if they could easily switch between IdPs (so we could use the beta.login.ufl.edu IdP for debugging, but then switch to the production login.ufl.edu IdP). This is not a requirement, but it can make the onboarding process faster. Without this, debugging any issues will be much slower since any change to the configuration will not go into affect until the following business day.
  5. For SAML2 implementations, if the vendor has specific needs for the NameID, we need to know what they are. This should be in the SAML2 documentation, but is sometimes omitted.

The steps for modifying/removing an existing SP are:

  1. A request to modify or remove an existing SP must come from one of the contacts for the SP. To verify the description of the SP, log in to the SP Registry and review the current SP.
    • Select “Search SP Database”
    • Type the SP Group Number, Group name, or any of the other search criterion and click “Display SP Groups”
    • Click on the SP Group that you are trying to investigate
  2. Changes to an existing must be made by creating a ticket. Submit the UF Service Provider Request by ticket to the IAM Team. Tickets should be created by the ISM or the Technical Contact for the SP being requested. Create Ticket.
  3. If there are significant changes to an existing SP, it may require a new or updated risk assessment.
    • The Identity Services Team will request this if it is needed.
  4. The ticket will be handled by the IAM team.

Recertifying an SP group

Each SP group needs to be recertified on a yearly basis. Recertification consists of confirming that all of the contact information is accurate so that we can contact the appropriate people in the case of a security or technical incident, or of changes that could impact the SP. SPs are recertified by anyone listed as a contact for that SP. When recertification is due, an email will be sent to the contacts so they can recertify it. SPs that do not recertify in a timely fashion may be disabled and will not be re-enabled until the certification is complete. To certify an SP group for which you are the contact: 1. Log in to the SP registry 2. Click on the ‘Recertify SP Groups’ button. 3. In each SP that you wish to recertify (which should include any that are listed as ‘Recertification overdue’ or as ‘Certification expiring’), verify that all contact information is accurate. The rules for what contacts are required is included on this page. Update or verify the information and then click on the checkbox in the ‘Recertify’ column. 4. Click on the ‘Submit Recertification’ button to submit the results. It is not necessary to wait until an SP group is overdue or expiring. Any time the contacts change (perhaps due to someone leaving the organization or someone being hired), the SP group can be recertified with the new contact information which will reset the annual clock.

Other SP Tasks:

  1. Uploading metadata. When a new SP is created, you will need to send us a copy of it’s metadata (unless it is in InCommon or it is an OIDC implementation). After you have obtained a copy of the metadata, upload it at the UF SP metadata URL
  2. When configuring an SP with a vendor, you will need the metadata from the IdP.