Wandering Thoughts archives

2023-02-26

Universities are often environments with distributed accounts and identities

Over on the Fediverse, I said something about university account systems:

Welcome to the university. We have a central account and identification system, of course. Does everyone use the central account system? Of course not. Does everyone know what central account IDs their local accounts have? I see you're new here. Is there always a one to one mapping between local and central accounts? Not a chance.

Universities are fun places.

There are all sorts of reasons for this distributed and anarchic environment. An obvious one is that some of the local systems can predate the central one. Universities have generally long had the idea of 'identities' for staff, students, and professors, but these identities haven't been exposed as computer things, with passwords and an authentication system that other people could use. Instead these identities existed in databases, often in separate ones depending on what sort of role a person had (staff were in the HR database, students were in the registrar's database, and so on). For a long time local areas were left to build their own systems to create a merged view for people they cared about.

Related to this, even once a central computer account database existed, it was generally not widely available to arbitrary people without a lot of work. Some of this is (or was) simply the state of software for delegating accounts and authorizations to third parties, but beyond that universities are in the unusual position where this central database can hold a lot of sensitive information, what is often called 'Personal Identifiable Information (PII)'. A university database of 'all people here' necessarily includes 'all of the students here', often with some amount of juicy information that needs to be exposed in order for authentication systems to be useful.

(And in the days before MFA, allowing arbitrary parties within the university to use your central authentication service also potentially enabled mass attacks against people's valuable central accounts. Dealing with this is a complex issue, one that requires real resources and doesn't always have good answers, partly because a university has some unusual threats. For example, sometimes students are happy to attack each other.)

Another issue is that a university wide account is sometimes too powerful of a thing. If there is an outside professor or researcher visiting one department for a month, the university as a whole may not want to issue them an account that will give them central email, enroll them in various things the university is licensed for, and so on. And then when they leave at the end of the month, the university may want to deactivate the account but the department may not, because the department wants to foster an ongoing relationship with that person.

Additionally, once you have local accounts one thing that people start wanting is additional accounts for projects and the like. These accounts will belong to someone, but they're not the person's primary account (and who the account belongs to can change over time). Project accounts are especially important in an environment where a lot of projects are done by graduate students who do graduate and leave (we hope), but professors often want to keep them around and perhaps running.

tech/UniversityAccountsDistributed written at 22:50:42; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.