This document outlines the Service Level Agreement (SLA) for the campus community's Single Sign-On (SSO) service.
SSO is a cloud-based service provided by the vendor, Okta, 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.
- 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)
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.
- 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 ID 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.)
- 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.
- 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
- Session time-out (20 minutes)
- 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.
- For SSO services that utilize Shibboleth authentication, the Shibboleth token will expire after 20 minutes of inactivity. This means that if a user is inactive for 20 minutes, they cannot navigate directly to a Shibboleth service without being prompted to login.
ASP Service Elements
- 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.
- 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.
- 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
- Dynamic service link
- 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 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.
ITS RESPONSE TIME*
(Regular business hours)
Within 1 business hour
All customer support will be available by calling the ITS Desktop Support line at 562-985-8344, including after hours, weekends, and holidays. An internal ITS process is in place for escalating incidents or events to proper channels.
(After business hours)
Within 4 hours
By 11:30 am the next business day
*Note: Response time is defined as the time between initial report of trouble and time an ITS staff person contacts the customer to begin resolving the issue.
ITS will strive to provide 100% service uptime. As a SaaS, Okta's SLA is currently 99.6% up. Offline/Continuity procedures are in place should an outage impacting Okta's service occurs users will be directed to a standalone service list page where they can access service. Downtime excludes planned maintenance. System monitoring will be provided by System Center Operations Manager (SCOM).
ITS will exercise a routine schedule for OS updates, firmware upgrades for blade servers, VMware maintenance release upgrades, storage maintenance, and network and data center maintenance as applicable. As stated in Change Management section 4.6, advanced notifications will be provided and tested in development environments. A set window of time for standard maintenance will be established for quarterly database maintenance. A set maintenance window will also be identified for windows maintenance.
Unplanned service degradation, interruption, or outage will be managed through the ITS Incident Management process whereby ITS will send ASP notification and details about the problem, downtime, and other pertinent incident information. ASP will provide ITS with a current list of notification recipients. See Appendix A for the notification recipient list.
Recurring incidents/issues will be managed and escalated within ITS as needed. ASP will communicate concerns about incidents and problems to the Director, Service Management & Operations as soon as possible. Appendix A provides a list for contacting appropriate parties.
Any maintenance or changes will follow the ITS Change Management process, which involves a review and approval of documented change requests by the ITS Change Management Board (Appendix D). When necessary, the process may involve a Change Management Notification to an ASP prior to the change. When possible, ITS will notify ASP a minimum of 24 hours in advance. However, the nature of the change activity will determine the amount of time of the advance notification. If able, a coordinated change time will be established to give ASP time to update documentation if look and feel changes are implementdd. For example, if the change requires preparation activity by the ASP, notification will be provided several days in advance, and if the change is urgent, less than 24 hours' notice may be provided. In some cases, change activity will involve detailed discussion between ITS and ASP technical staff before change activity is approved by the Change Management Board. Emergency Changes will follow the ITS Emergency Change process.
ITS will repair or replace existing equipment at no additional charge for servers covered under this SLA.
Disaster Recovery / Service Continuity
Disaster Recovery / Service Continuity services are available as part of this agreement. Requirements for server recovery and business priority must be identified by an ASP and accepted by ITS to ensure recovery activities are agreed upon before disaster situations. This service is forthcoming and will be initiated at an agreed upon time.
Server security and firewalls (data center firewall) services are included in this agreement. Access management will be provided via server security and data center firewall as requested by the ASP and/or required by application. For services utilizing Shibboleth authentication, ITS will only release Level 2 or Level 3 information to service providers. Notice triggering information will not be released, no exceptions.