Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reorganized information to be more clear about delineation of responsibilities.

...

"I have reviewed the MyAccess Integration Kit and I have read, understoodunderstand, and agree to the Identity Provider and Service Provider responsibilities listed in the Shibboleth Integration Support Responsibilities and Agreement."

Identity Provider (IdP) - Identity and Access Management Team

...

General issues

...

(Us)

The Identity and Access Management team is responsible for maintaining the UCSF MyAccess Identity Provider and related infrastructure, which consists of the following:

  1. Supporting and updating Shibboleth IdP software on a regular basis.
  2. Notifying departmental technical contacts of any updates and changes to the IdP and allowing adequate time for testing before changes are migrated to the production IdP.
  3. Maintaining relationships with the InCommon and UCTrust federations, including registering IdP metadata updates as appropriate.
  4. Configuring the IdP for both UCSF campus service providers and federated service providers, which includes loading SP metadata into the IdP.
Explanation:

The Identity and Access Management (IAM) team provides general consultation and documentation on how SAML works to help an application owner know how to integrate their application with MyAccess - see .  See the MyAccess Integration Kit for some of this documentation. The IAM team can make recommendations about what type of setup would be best for an application. However, it is up to the application owner person responsible for integrating the application (you) to implement the setup, or to arrange for others to do so.

The Identity and Access Management team cannot provide programming or application customization services and cannot support Service Provider software installation, configuration and maintenance because.  Here's why:

  • There Scale.  There are hundreds of Service Providers across campusboth on campus and off campus already integrated with MyAccess, each with a unique systems system infrastructure and environment.
  • Many Scope.  Many applications require multiple servers, load balancing, and database configurations, network configuration and firewall modifications which requires a complex an in-depth understanding of that application's unique environment.  Time requirements to learn all necessary information for all environments is beyond the staff resource limitations of the Identity and Access Management team.For security purposes, the requirements.  The people most familiar with the inner workings of the application are thus best suited to the task of making necessary changes to the application to support the MyAccess integration.
  • Security.  The Identity and Access Management team does not, and should not have access to the web servers where on which the Service Provider software runs.
IAM Responsibilities

The Identity and Access Management team is responsible for maintaining the UCSF MyAccess Identity Provider and related infrastructure, which consists of the following:

  1. Supporting and updating Shibboleth IdP software on a regular basis.
  2. Notifying departmental technical contacts of any updates and changes to the IdP and allowing adequate time for testing before changes are migrated to the production IdP.
  3. Maintaining relationships with the InCommon and UCTrust federations, including registering metadata updates as appropriate.
  4. Configuring the IdP for both UCSF campus service providers and federated service providers, which includes loading SP metadata into the IdP.

Service Provider (SP) - Application Owner

General issues

Since the Service Provider (commonly referred to as an "SP") integrates with the application's web server, support for the Service Provider must be provided by the application owner's system administration team.

System administrator teams should do the following:

  1. Become well versed in how MyAccess/Shibboleth works. The Identity and Access Management team can provide training.
  2. Join the Internet2 Shibboleth user mailing list and post questions when there are issues
  3. Proactively monitor the Shibboleth SP process (not applicable for SimpleSAMLphp)
  4. Run a non-production Shibboleth SP to test patches and be familiar with the software update process. For example, various Linux distributions behave differently when the Shibboleth SP is updated.
Application Owner Responsibilities
  •  Only the application administrators and the system administrators for the application servers should have this level of access.
  • Resources.  Time requirements to learn all necessary information for all applications in all environments is beyond staffing limitations of the Identity and Access Management team.

 

...

Service Provider (SP) - Application Owner (You)

Departments wishing to integrate with MyAccess will need a variety of staff to support migration efforts and maintain the integrations over time. If a department does not have internal staff with the necessary skills to support a SAML Service Provider, it must contract with an outside system administration service.

The section below describes specific Service Provider responsibilities and who typically performs the work.

Responsibility

Staff

Shibboleth Integration Project Management

Application owner/department

Determining data needs

Application owner/department

Submitting data release requests, including to other institutions when federation is appropriate

Application owner, IAM Team

Installing, configuring, upgrading and maintaining over time all server-side software need to run Shibboleth

Departmental system administrators

Providing a Service Provider test environment so that software patches and upgrades can be adequately tested prior to release in production

Application owner

Monitoring of the Shibboleth service to ensure it is running

Departmental system administrators

Identifying, troubleshooting, testing, and resolving issues (including multiple servers, load balancers, database setups, etc.)

Departmental system administrators, departmental developers, IAM team in a consulting role

Developing and sending communications to end users

Application owner/department

Providing a point of contact for end users experiencing problems

Application owner/department

Explanation:

Since the Service Provider (commonly referred to as an "SP") integrates with the application's web server, support for the Service Provider must be provided by the application owner's system administration team.

System administrator teams should do the following:

  1. Become well versed in how MyAccess/Shibboleth works. The Identity and Access Management team can provide training.
  2. Join the Internet2 Shibboleth user mailing list and post questions when there are issues
  3. Proactively monitor the Shibboleth SP process (not applicable for SimpleSAMLphp)
  4. Run a non-production Shibboleth SP to test patches and be familiar with the software update process. For example, various Linux distributions behave differently when the Shibboleth SP is updated.