EITS provides multiple services for central authentication at UGA using MyID credentials and, optionally, ArchPass two-step login, powered by Duo.
Each service is comprised of an authentication server and an application client, which redirects calls for authentication to the authentication server.
Our enterprise-wide UGA Single Sign-On Service (UGA SSO) uses the Apereo CAS application (https://www.apereo.org/projects/cas) as the central authentication server.
UGA SSO supports three protocols: CAS, SAML, and OIDC. Clients are installed and supported by application administrators throughout campus.
Note: EITS Identity management can offer only limited assistance for the client as each application may differ in the client implementation.
For more information please visit our FAQ page.
Central Authentication Service (CAS)
Central Authentication Service (CAS) is the term used for both the authentication service running on the UGA SSO servers and a protocol used in our single sign-on implementation.
The CAS server is a Java servlet whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets.
A Single Sign-On (SSO) session is created when the server issues a ticket to the user upon successful login. A service ticket (ST) is issued to a service at the user's request via browser. The ST is subsequently validated at the CAS server via back-channel communication.
Attribute release
The CAS service supports the release of a limited number of identity attributes.
Application owners must work with the application support vendors to determine attributes needed, properly map the attributes and ensure access is provisioned.
The following attributes are currently available to release via SAML 1.1 and 2.0 through our enterprise CAS service. These are the labels as the attributes are released:
- CN (Common name, should be same as MyID)
- DN (Fully qualified distinguished name from MSMyID )
- firstName
- lastName
- If you require more information, please elaborate on the access form.
NOTE: The CAS service provides support for the SAML 2.0 protocol with backwards compatibility for SAML 1.1. New applications will default to CAS 2.0.
SAML
Security Assertion Markup Language (SAML, pronounced sam-el) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. As its name implies, SAML is an XML-based markup language for security assertions. It is one of the protocols supported by UGA SSO.
Elements
- Web Browser: Represents the user within the SSO process. The SAML protocol relies on HTTP headers and HTTP redirects.
- Identity Provider (IdP): Sometimes called an Identity Service Provider or an Identity Assertion Provider, this is an online service or website that authenticates users on the Internet by means of security tokens. Service Providers depend on an Identity Provider or Security Token Service to do the user authentication.
- Service Provider (SP): This is a system entity that receives and accepts an authentication assertion issued by a SAML identity provider.
Metadata
A SAML metadata document describes a SAML deployment, such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability. When registering Service IDs for CAS/SAML authorization, accurate and compatible metadata from the service provider is required.
UGA Implementation
Environments
The UGA enterprise CAS service utilizes the current version of Apereo CAS software. EITS maintains three instances for development, staging, and production. These instances are at the following addresses:
- Development: sso.dev.uga.edu. Uses development credentials. Test accounts and additional configuration of development MyIDs may be necessary to test authentication. For more information and to checkout test MyIDs, visit our Test MyID checkout form.
- Stage: sso.stage.uga.edu
- Production: sso.uga.edu
Protocols supported
Request process
Departments or units who want to add applications to any UGA SSO environment and enable SSO authentication should submit an integration request using the SSO Integration Request Form.
In the SSO Integration Request Form, the application owner will be asked to supply the following information:
- The URL for each environment: Dev, Stage, and Prod
- The attributes that can be returned to your application
- Indicate if the application will use ArchPass two-step login, powered by DUO.
- Indicate the protocol that will be used for the SSO integration. If the protocol desired is SAML, EITS will need the metadata file or metadata link for the application
- The timeframe for moving the configuration into the production environment
The request will initiate a workflow that will be handled by EITS Information Security and Identity Management teams. The application owner/requestor will be contacted within the ticket with any questions and updates regarding the SSO integration request.
All new applications added to the SSO environment start in the SSO development environment.
Please plan for at least eight weeks, if no issues are identified, from initiation of the request to the scheduling of the application production go-live date. Newly registered applications will be subject to review and vulnerability scanning by the EITS Information Security team.
Testing the Configuration
All testing to determine if the SSO integration is working properly is the responsibility of the application owner.
There are multiple steps within the SSO Integration ticket workflow where the application owner will need to attest that they have tested the integration and that it is working properly.
If test MyIDs are needed, they can be checked out to test authentication while onboarding your application. If the application has special authorization criteria based on a local user base or attributes being passed, test accounts can be set up to mimic the specifications. Test accounts can be requested via the Test MyID checkout form.
UGA Application Listserv
Application owners are automatically added to the UGASSOApps Listserv. This list is used for communications about SSO service maintenance, disruptions, or announcements. Application owners can also use this list for tips, techniques, and general questions about applications connecting to UGA SSO. This list is a discussion list and is not moderated before posts. By accepting your understanding of the authentication methods at UGA, you are also accepting, as an application owner, that you will participate in the listserv communications.
UGA SSO Maintenance Windows
The EITS Identity Management (IDM) team provides regular SSO maintenance windows to add or modify SSO configurations in the production UGA SSO environment. These maintenance windows are typically scheduled twice a month, on Friday evenings starting at 5 p.m. Emergency maintenance will be conducted as needed. While preparing for an upgrade to the UGA SSO system, maintenance windows will be suspended temporarily to allow all application owners to test their applications with the updated CAS version, prior to the update being added to the production environment.
For more information about UGA SSO and moving your application, please visit our Moving to UGA SSO page.