Penn Computing

Penn Computing

Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn

Service Provider Information Packet

This information packet is intended for customers who have identified federation as the best means of using Penn as an identity provider. This can be used for a more in-depth understanding when moving into the intake meeting but is primarily aimed at informing the customer about the details of federation independent of the InCommon choice.

Contents

ISC Support Model

ISC’s primary responsibility is the maintenance of the IdP and support for the federation process for SPs communicating with the IdP. As a result, ISC is unable to staff or support the installation or configuration of federation software such as Shibboleth. During validation of a configuration, ISC will be available for validation of the connection between the IdP and SP, but in the event that the problem lies on the SP side, ISC will be unable to troubleshoot the problem.

SP Support Model

Because of the limits on the support that ISC is able to provide during the setup of a service provider, the customer will need to provide the resources necessary for the project. The choice between internal resources, vendors and contractors for such a project will depend on the customer’s resources. ISC will be available for conversation to help the customer determine which choice is best given the circumstances.

In addition to the resources needed for the initial project of setting up a service provider, the customer will also need to have persistent support through the life of the federation product. As will be discussed in the Maintainenance Schedule section of this document, the customer will need support to participate in the maintenance and potential repair of the service provider. This support will be needed for metadata updates and revalidation of the configuration and for repairs should they be needed.

SLA

ISC Shibboleth Identity Provider Service Description

  • Highly available
  • Fault-tolerant
  • Redundant
  • Monitored
  • Supported on call 24/7

Maintenance Level

  • Emergency Maintenance – as much advance notice given as possible
  • Scheduled Maintenance – minimum one week notice
  • Regular Maintenance – 60 days notice to allow to project support to be arranged

ISC Provider Desk (ProDesk) Hours

ProDesk is a phone and email support service designed to serve the needs of service providers. ProDesk is available to help troubleshoot issues surrounding federation with the Penn’s IdP.

Tickets can also be opened through Remedy.

Service Provider Registration Request

This Service Provider Registration Request Form is intended for any school or center that wants to become a federated Service Provider using Penn’s Shibboleth IdP as an Identity Provider. Federated authentication allows for web-based applications to accept credentials from Penn users. If this application is also registered as a service provider under InCommon, it will be able to accept authentication from all organizations in the InCommon Federation (http://www.incommon.org/participants/).

Request Process:

  1. Complete the Penn Service Provider Registration Request Form and submit to the ISC Provider Desk.
  2. ISC will review the request and work with the requesting department. The ISC team will recommend any changes or adjustments.
  3. The request is accepted or denied.
  4. The requestor implements the service as approved.

Most customers need to consider how testing will be done, and whether a test service should be included. This is a preferred and recommended practice. For some larger customers, multiple test and development areas might need to be established for the service provider (SP) to deploy applications. On the form, please indicate the environments needed as part of your service provisioning and management.

Best practice is to cluster your web applications such that there will only need to be a single host exposed to register as a service provider. Ideally, not more than three services (one per environment for the application) will need to be registered. If for technical reasons more than three services need to be registered, please indicate this clearly on the registration form.

Service Provider Setup Project

In the event that the customer does not already have federation software in place, it will be necessary to install and configure a federation product. ISC strongly recommends Shibboleth for the service provider although, ultimately, any SAML2-capable product will work. If the customer already has federation software in place, it will still be necessary to import and share the existing metadata and validation the federation.

Drivers

When commencing such a project it is useful to know the driving forces behind the project, such as who has an interest in seeing the project completed or if a particular event is guiding the process. Local executive sponsors and IT directors may need to be engaged to make project-level decisions.

Scope

The scope of a setup project will depend on whether the customer needs a service provider installed and configured or whether one already exists. If one already exists, then some of following steps for a single “environment” may be omitted.

  • Installation of a federation product / deployment on an application/web server
  • Configuration of the federation software to protect the target application
  • Import of IdP and SP metadata
  • Distribution of SP metadata to IdP
  • Validation of the federation process

ISC recommends that customers set up three separate environments as part of this project:

  • A development environment for understanding and following the process and resolving any environment-specific details not detailed in the processes.
  • A test (or quality assurance) environment for ensuring repeatability of the processes used in development, for resolving any further issues and for load-testing.
  • A production environment for the live operation of the application and federation software by real users.

Further, the application will need to be modified to accept trusted external authentication and to receive external attributes as part of the authorization path.

Requirements

If the customer needs to place any constraints on the shape the solution takes, that needs to be expressed here. Constraints may be technical in nature (e.g. limitations on operating systems, federation software or the SAML2 standard) or they may be business constraints (e.g. attribute release conditions).

Constraints for Penn federation projects include:

  • Shibboleth is the federation product used by the IdP.
  • SAML2 is the standard the IdP will be using to communicate.
  • Penn can only release certain attributes.
  • InCommon places technical and business restrictions on assertions and their use.
  • Hybrid authentication solutions will not take place within the IdP. If desired, perform such solutions within application.

Impact

This project may impact the uptime or performance of the application and the server the new SP will be running on, or firewall settings for exposing a new server for external visibility.

Schedule

The project will require some number of hours for requirements gathering at the outset of the project. If the application needs to be modified to accept authentication or perform authorization this will also require some time. Barring unforeseeable difficulties, each environment should take the same amount of time to set up. Any load-testing in the test or production will require additional time. Satisfactory completion of any production load-testing and the SP Validation Guide should mark the end of the project.

One sensible order in which the project might proceed is listed under Scope.

Metadata

To configure a federation entity to communicate with other providers, there needs to be an exchange of information regarding where to send message and how those messages will be validated. Metadata files are how that exchange takes place. The metadata files may either be manually exchanged or posted at a publicly available URL. A metadata file contains endpoint URLs for a provider’s federation services and certificates to verify the identity of any messages purporting to be sent by that provider. Penn distributes its metadata in a bundle that you must request from ISC.

InCommon makes its metadata available at the below URL:

http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml

IdP Customizations

Penn has groups of attributes it releases as a member of the InCommon federation. The customer and Penn will need to identify which attributes the application needs to perform authorization and which it needs to correctly personalize the application for the user. If attributes beyond those offered by Penn, the customer will need to contact ISC and discuss the situation.

Maintenance Schedule

ISC will perform quarterly maintenance to maximize uptime. Once per quarter, ISC will update the attributes it can offer for release, update its metadata and onboard new customers. Customers will need to have resources available to support this maintenance (e.g. updating and validating new metadata).

ISC will also make updates to the IdP software and host machine’s operating system biannually. IdP software updates should not affect the compatibility of service providers. Customers may choose to make update to their service provider on this maintenance schedule or some other schedule. Any updates to service provider software are still subject to the ISC and SP support models detailed above.

Scheduled maintenance will be announced in advance to the mailing list for Shibboleth providers and via the ISC maintenance calendar.


Service Alerts

top

Information Systems and Computing
University of Pennsylvania
Comments & Questions


Penn Computing University of Pennsylvania
Information Systems and Computing, University of Pennsylvania