Service Level Agreement for Single Sign-On (SSO)

Table of Contents

1. General Overview
2. Background
3. Duration of the Agreement
4. Parties
5. Service Details
6. Service Description
7. SSO Environment Elements
8. SSO Environment Provider (SEP) Responsibilities - ITS
9. ASP Responsibilities
10. SSO Governance Committee (SGC) Responsibilities
11. Application Service Provider SSO Participation Technical Requirements
12. SSO Integration Steps
13. Service Provider Access Control Process
14. Service Commitments
15. Service Hours, Response Times, and Trouble Reporting
16. Service Availability
17. Scheduled Maintenance
18. Incident Management
19. Problem Management
20. Change Management
21. Repair
22. Disaster Recovery / Service Continuity
23. Security 

General Overview

This document outlines the Service Level Agreement (SLA) for the campus community's Single Sign-On (SSO) service.

Background

SSO is a cloud-based service provided by a third-party vendor, and administered by Information Technology Services (ITS). SSO provides an environment where participating Application Service Providers (ASPs) can present access to their services to customers through a single login process. The process authenticates a customer for all the SSO-enabled applications they have been given rights to and eliminates further log in prompts when they switch applications during an SSO session.

Duration of the Agreement

This SLA will be reviewed annually based on the fiscal year. ITS may make SLA alterations throughout the duration of this agreement.

Parties

• SSO Environment Provider (SEP)
  • Information Technology Services
• Application Service Providers (ASP)
  • Enrollment Services – EAB, Symplicity, HRSA
  • Information Technology Services – CSLink, MyCSULB
  • Academic Technology Services – BeachBoard
  • Staff Human Resources – HRSA
  • Financial Management – CFS, DataWarehouse, CFS Information
• SSO Governance Committee (SGC)

Service Details

Service Description

SSO enables customers to enter their user name and password (BeachID credentials) at a single location (https://sso.csulb.edu) and access multiple services without having to log in again. SSO service attributes include a single entry point (login process), a dynamic and/or static service list of participating applications, and logout processes.
After logging into the SSO environment with a browser that's enabled for pop-ups, the customer accesses participating services by clicking an application service link or bookmark. The selected application is then presented in a new tab within the current browser or a new browser window, depending on the user's browser configuration, and will not require the user to log in again to the participating SSO service. The SSO environment will work with standard browser types and versions (for example, Internet Explorer, FireFox, Chrome, Safari, etc.); however, SSO-browser compatibility does not supersede requirements for using specific browser types and versions with an ASP service.

SSO Environment Elements

The SSO Service environment includes Login, Service List, Logout, and ASP service elements.

Login

• Customers will be presented with a single login entry point, https://sso.csulb.edu, and process.
• Authentication is accomplished using active BeachID credentials (Username: Campus Email Address and Password: BeachID password).
• Customers experiencing SSO log in problems will follow existing support procedures for BeachID-related services. (See Appendix E for support processes.)

Service List

• Upon successful login, customers will be presented with a page that contains a list of participating services displayed as a set of hyperlinked tiles.
• Participating services may be presented on the Service List page through a static process (allowing a participating service to be seen by all users, or users with a student, staff, or faculty role) or a dynamic process (allowing a participating service to be seen by authorized customers based on user and group criteria and automated via access control lists provided by the ASP)
• For example, BeachBoard will be viewed by all, and EAB will be viewed only by customers designated by the ASP through the Service Provider Access Control Process. (See Section 2.2.)
• The Service List page cannot be customized or augmented.

Logout

• SSO session logout can be accomplished by:
  • Clicking the sign-out button on the Service List page
  • Closing the browser tab displaying the Service List page
  • Closing the browser
• SSO session sign-out may not complete the logout process for participating applications.
• Once the user clicks the sign-out button, an SSO logout message will inform the user that all browser windows and tabs must be closed to fully log out of the SSO session and all related applications.

ASP Service Elements

• Authentication
  • Participating SSO services must use BeachID authentication. Preferred authentication types for SSO are Shibboleth (InCommon federated) or Microsoft ADFS services. Other authentication types such as Active Directory (AD) or Active Directory Lightweight Directory Services (ADLDS) will be considered on a case-by-case basis.
• Customer Communication
  • ASPs will communicate with their customers all aspects of their service and the SSO service including how to access, how to get help, how to logout, and any other service-related information.
• Customer Identification
  • Each ASP will identify customers of its participating services by group and/or user role(s). SSO environment access will be integrated based on ITS requirements and application limitations.
  • Static access: The participating service is displayed to all SSO-eligible users or some users based on student, faculty, staff roles.
  • Dynamic access: The participating service is displayed only to specific SSO-eligible users as automated through the Service Provider Access Control Process (See Section 2.3.)
• Customer Support
  • ASPs will provide customer support for their applications. The Technology Help Desk or ITS Desktop Support Group will escalate SSO support calls to the appropriate ASP technical support group if a customer problem occurs subsequent to selecting a Service List link/tile/bookmark.
  • ASP will document support processes for each of its SSO-participating applications to ensure proper escalation procedures can be followed by customer support organizations.
  • Logout
    • Each ASP will support logout functions within its applications.
    • If technically feasible, an application logout function may be integrated with the SSO logout to maintain single logout.
    • Each ASP will support inactivity/session-initiated logout functions within its applications.
    • ASPs utilizing Shibboleth, logout functions within the application must destroy the Shibboleth session.

SSO Environment Provider (SEP) Responsibilities - ITS

• ITS will maintain an SSO production environment.

• ITS will support SSO login and logout functions through existing support processes for BeachID-authenticated services.
• ITS will support the Service List page look and feel and bookmark functionality.
• ITS will work with ASPs to implement and update automatic, dynamic service links subject to "SSO Technical Integration Guide" requirements in Section 3 of this SLA.
• ITS will provide service continuity if the SaaS vendor environment is unavailable.
• ITS will communicate and coordinate changes with ASPs to ensure minimal service disruption. (See Change Management, Section 3.6, and Incident Management, Section 3.4.)
• ITS will maintain and facilitate vendor support agreements for the SSO environment.
• ITS will work with ASPs and coordinate with the vendor to assist in troubleshooting problems that may be related to the SSO environment.
• ITS will install all SSO software updates.
• ITS will maintain all SSO environment operating systems and follow current ITS standards for performance, stability, and security, unless otherwise required by vendors and/or manufacturers.
• Notification about operating system patches and updates for production servers will be communicated and coordinated through the ITS change management process. ITS will follow its standard patch and update schedule unless an exception is necessary.

ASP Responsibilities

• The ASP will maintain services that are accessible via production web link(s) on the Service List page.
• The ASP will provide ITS with advanced notification about service-interrupting, planned maintenance for participating services by emailing ITS-ServiceManagement@csulb.edu. Whenever possible, the ASP will provide at least five business days of advance notification for planned maintenance. If a participating service adheres to a routine, service-interrupting maintenance schedule, the ASP will provide such schedule to ITS.
• ASP will provide ITS with timely notification when unplanned outages occur by emailing ITS-ServiceManagement@csulb.edu.
• The ASP will provide a maintenance web page for its participating service to be used when service is unavailable. Maintenance and outage information for a participating service cannot be displayed or presented on the SSO Service List or related SSO pages.
• The ASP will maintain a non-production environment to test SSO/authentication integration.
• The ASP will support logout functions for its participating services through existing support processes for BeachID authenticated services.
• The ASP will work with ITS to implement and update automatic, dynamic service links according to ITS requirements.
• The ASP will maintain and facilitate vendor support agreements for the their respective services.
• The ASP will maintain and facilitate customer support for the their respective services.
• ASPs will communicate to their customers the requirement for browser pop-ups to be enabled for the SSO service to work properly.
• ASPs or their delegate will communicate to their customers logout procedures for participating services and SSO service to emphasize that service-logout functions are often independent of the SSO environment. (For example, click logout within the application, and then close the browser to fully exit the participating service and the SSO session.)
• ASP or their delegate will communicate to their customers all browser requirements for their participating service to function within the SSO environment. Browser requirements for participating services may be narrower or at a lower standard than those for the SSO application. ASPs are responsible for working with vendors or application providers as needed to ensure sufficient browser compatibility is available for a participating service to work with the SSO environment.

SSO Governance Committee (SGC) Responsibilities

• Determine ASPs and services that may participate in the SSO environment. (Due to vendor licensing constraints, the SSO environment is currently available to active students, faculty, and staff only. Alumni, admissions applicants, admitted applicants, and other customer groups are currently out of scope..)
• Approve participating services that must meet the following criteria in addition to meeting technical requirements:
  • Meet the technical criteria outlined in section 3 in this SLA
  • Reaches established and approved customer groups
  • Advance student success
• Provide final decisions on changes to SSO environment look and feel within the technical limitations of the environment.Application Service Provider SSO Technical Integration

Application Service Provider SSO Participation Technical Requirements

Service providers who would like to participate in the SSO environment can request participation by emailing ITS-ServiceManagement@csulb.edu. To be considered, the prospective SSO service must meet the following criteria:

• Service must be web-accessible.
• Service must be authenticated with BeachID.
• ASP must maintain a production and development environment for the service.
• Participation must be approved by the SGC.
• ASP must identify customer group(s) who will see the service link. If service link is dynamic (that is, visible only to customers with service access), ASP must follow the Service Provider Access Control Process as outlined in section 3.3.
• ASP will manage the system of record for user access control. ITS cannot manually add, remove, or modify user access within the SSO environment.
• ASP service must maintain independent logout functionality.
• ASP service must support inactivity/session-initiated logout functions within its applications.
• ASP service must conform to campus and campus SSO environment requirements and limitations for security as well as browser and device compatibility.

SSO Integration Steps

SGC-approved ASP applications are integrated into the SSO Environment according to the following steps.

Planning (ITS requires two weeks for this phase.)

ASP provides ITS with:

• a list of customers (Static or Dynamic access to the participating application; dynamic access requires creation and maintenance of a DBView)
• a service link (URL); entity identification and the required attributes If the service will use Shibboleth (InCommon federated)
• the service graphic image used for the SSO Service Link.

Testing (ITS requires two weeks for this phase.)

• Build SSO service entity
• Assign to test account or test group
  • Dynamic service link
    • ASP creates DBView and provides ITS with credentials
    • ITS creates FIM security group automation
• Test non-production service link against non-production authentication source both directly to the service and through sso.csulb.edu
• Test non-production service link against production authentication source both directly to the service and through sso.csulb.edu
• Test non-production service link within SSO environment

Implementing (ITS requires two weeks for this phase.)

• Modify SSO service entity
  • Static service link – apply to all or existing roles as defined by ASP (for example, staff, faculty, students)
  • Dynamic service link – ITS to utilize FIM security group for production
  • ITS publishes service link for applicable customer groups
• ASP communicates with customer groups about its service access and all SSO-related processes such as logout, browser and browser pop-up requirements, and support processes.
• ITS adds service link to continuity page

Service Provider Access Control Process

ASPs are responsible for controlling, auditing, and identifying customers who will have access to their service link(s). To use dynamic processes that display a participating service link only to authorized application users, ASPs must meet the following requirements:

• Provide ITS with a database view into ASP system of record that contains a single column of campus IDs for customers who will have access to the application
• The ASP manages user-list changes only within the system of record for the participating service
• The Database View will be used for delta-changes at frequencies established by FIM
• ASPs who want static access for a participating service (access for all customers or simply by student, faculty or staff role) are not required to follow the Service Provider Access Control Process.

Service Commitments

Service Hours, Response Times, and Trouble Reporting

ITS will provide 24 X 7 X 365 server monitoring. The following table details Service Hours, ITS response times, and the trouble-report process.