Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


To integrate with MyAccess, you must affirm the following statement. You will submit this as part of your integration request.

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

Identity Provider (IdP) - Identity and Access Management Team (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.

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 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 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.  Here's why:

  • Scale.  There are hundreds of Service Providers both on campus and off campus already integrated with MyAccess, each with a unique system infrastructure and environment.
  • Scope.  Many applications require multiple servers, load balancing, database configurations, network configuration and firewall modifications which requires an in-depth understanding of that application's unique 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 on which the Service Provider software runs.  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.



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


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.


  • No labels