This is a situation where it might be helpful to mentally separate “authentication” and “authorization” as two separate functions.
“Authentication” is the process of a person identifying themselves and providing credentials proving their identity. “Authorization” is the process of deciding whether or not that person is allowed to access a particular resource.
The purpose of CAS is to physically separate those two functions. CAS provides authentication services only. When a person has been authenticated, CAS notifies the requesting application that “User XYZ” has logged on. It’s up to the individual applications to decide whether or not User XYZ can access any particular page.
As a result of this, what CAS provides back to the application is the name of the user who has authenticated. What the django_ng_client does with that is then map that name back to a local User object for subsequent authorization throughout your system.
This is potentially a problem if there are any “naming conflicts” between services. It is possible for two people to have the same “CAS Username” in two different organizations - where one is a user of your service and the other isn’t.
The problem is that you don’t have control over the username supplied to you from CAS - and it’s not necessarily the username that the person logs in as. For example, I could configure a CAS server such that I log on to CAS as KenWhitesell, but CAS reports my username as KW12345 - because that is the username known throughout the systems “behind” that CAS instance.
Another factor in this is that every CAS system needs to be configured to allow your app to authenticate through it. This service name that I referenced earlier also works as a filter for CAS. CAS will not authenticate credentials from service names unknown to it. (I’m assuming you’re already working with the Universities for them to make those changes.)
(I’ve been working with CAS in our environment off-and-on for about 4 years now - I’m happy to help if you have any questions.)
Ken