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.

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.

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). 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.

SP Policy:

Since every SP using the UF single sign-on service represents a potential risk, the following are required of all SP owners.

  1. Every SP must have accurate contact information for a minimum of two unique contacts. Contact information must be verified (i.e. recertified) on an annual basis.
  2. SPs are expected to use current best practices for protecting the data that they receive. This means using encryption and signing of all data. Although exceptions may be made, it is expected that these will be short-lived and after an appropriate grace period, encryption will be required unless an extension to the exception is approved.
  3. SPs are expected to abide by principle of minimum access. The minimum required attributes should be used in order to perform the necessary function of the SP. SPs that have been assigned additional attributes should take the necessary steps so that the unnecessary attributes can be removed.
  4. SPs must maintain the needed certificates and metadata, including any updates needed due to expiring certificates. Expired certificates should not be used.
  5. All SPs must undergo a risk assessment in order to establish that the application that they are running is safe and the data is protected. An exception is that SPs which make use of an official “Fast Path” solution (an applicatin which has had a risk assessment and is deemed safe for all SPs) does not require a risk assessment.
  6. All SPs must be active. Inactive SPs represent security risks for no benefit. Once an SP has been inactive for 6 months, it will be deactivated. It can be reactivated upon request as needed.
  7. SPs must be registered in the SP registry in groups.  Each group represents SPs that run the same application (such as a situation where there are dev, test, qat, prod, etc. tiers) and are identical with respect to the information they need from the IdP.