Skip to Main Content



Protecting the integrity, confidentiality, and privacy of the information assets of the University of Georgia is the most critical mission for EITS. To continually improve our information security posture, we are upgrading a core service for accessing and signing on to University information services. This new single-sign-on authentication service, called UGA SSO, will be available July 20, 2019, for departmental systems to adopt.

All UGA web applications using the legacy versions of University’s authentication service must transition to UGA SSO. These mandatory transitions include applications using:

  • Central Authentication Service (CAS and CAS2)
  • Lightweight Directory Service (LDAP)
  • Identity Provider (IDP)

Timeline for Transitioning Applications

  • July 20: UGA SSO available for transitioning applications. EITS will no longer set up new applications on older authentication services (CAS, LDS, IDP)
  • November 1: Deadline for application owners to submit requests for test accounts to EITS
  • December 2: Deadline to submit requests to transition.
  • January 3, 2020: All application owners must have working solutions in dev for UGA SSO
  • February 3, 2020: All application owners must have working solutions in stage for UGA SSO
  • March 6, 2020: All applications must be moved to UGA SSO

All CAS2 applications will need to migrate to the new CAS UGA SSO system.

All LDS applications will need to migrate to the new CAS UGA SSO system. If you cannot do so, please contact or  as soon as possible.

Users will still need to use ArchPass, UGA’s two-step login solution, powered by Duo, for applications that require it. 

Application owners have until March 6, 2020 to migrate applications.  This means you will see the old CAS page for some applications until that time.

Application owners can disable the SSO for their applications by submitting a TeamDynamix request to

UGA SSO is a critical application.  EITS has regular backups, snapshots, and restore processes. EITS is working to improve resiliency for planned outages, such as data center and network maintenances. 

The UGA SSO application owners listserv (UGASSOAPPS@LISTSERV.UGA.EDU) is a great way to reach others who have applications that have migrated or are currently migrating.  Application owners are added to this listserv once their application completes security testing.

Transitioning applications 

To begin, a department should put in a UGA SSO Integration.  The request should include your completed project plan and test plan.

The request is sent to InfoSec for review, and then to IDM for the development work. 

Once the application has moved through development, the application owner must verify it works in development and sign off on the application. This process is also repeated for stage and production environments. 

You can find more information about the steps for transitioning applications in the UGA SSO Project Plan Template.

EITS must ensure all applications using UGA SSO have been security tested. Therefore, wildcards are discouraged.  In times of great need, IDM and InfoSec can work with departments.  Each case will be reviewed based on the need for security testing and application identification clarity.

EITS does not test applications in production. Departments should have development and test environments for testing future patches and releases. Applications with only one environment may need to schedule time to point to test and stage for departmental application sign-off. 

When you sign off on the workflow for development, stage, and production, you are verifying that the application is working as expected with your test plans.  Having the application owner sign off is critical to move forward in the workflow path for the UGA SSO migration.  Please make sure you sign off promptly when it is working in the environment to keep the workflow moving.

We are moving from five authentication services to one, UGA SSO.  This also means all applications at UGA share UGA SSO.  We know that many systems are very important to departments and the university.  To be mindful of the various needs of availability, 11 p.m. on Friday was the least impactful time for maintenances.   We work to ensure SSO updates are low impact. Some applications may not see any disruptions at all.  

Application owners should include the hosted environment’s contact information in their project plan.  Hosted applications follow the same process for migration – the application will need to tested in dev, stage and prod, and the application owner must sign off on each step.

The process for moving to UGA SSO is the same for a new or existing application.

Using authentication services is a very common industry standard for applications.  EITS does not have a list of all applications that can use our identity providers.

The SSO servers available are,, and 

Dev uses Dev AD. Please put in a request for test accounts. EITS can make those accounts look like production accounts if needed.  Stage uses production AD, so it will mimic production.

Auth.MSMyID will still be available for systems and services.  If you are using, you will need to migrate your application off the LDS service to UGA SSO.    If you are unable to do so, please contact or  as soon as possible.

Just because an application has made it through the procurement process, this does not mean they have successfully tested in the UGA SSO environment. All changes should be fully tested and verified.  We do not test in production.  UGA SSO is completely different hardware than other authentication services, so we need to ensure that everything is successfully tested and verified.

UGA SSO pulls AD attributes.  UGA SSO is an authentication service and not configured as an authorization service.  AD attributes can be sent to applications for authorization.

Security reviews will vary based on the application and environment.  Application owners can communicate to Infosec about their review via the comments in the tickets.

Most maintenance windows will not see a large disruption and most apps should remain working.

Application owners can put in as many dev instances as needed.

There are no plans to decommission or restrict access to Auth.