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 ugasso.uga.edu, ugasso.dev.uga.edu, and ugasso.stage.uga.edu. 

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 LDS.uga.edu, you will need to migrate your application off the LDS service to UGA SSO.    If you are unable to do so, please contact idm@uga.edu or shannon.marable@uga.edu  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.  

Our single sign-on service, UGA SSO, will undergo a scheduled maintenance around February and September each year. This maintenance is necessary to keep the service to a supported and secure system.   Application owners should  test their applications in dev and stage to ensure the updates does not impact their applications before the change is put in production UGASSO.  Since hundreds of applications share this environment, IDM and Infosec perform testing and troubleshooting of applications in our non-production environment.  A testing template can be found here.