Topics Map > University of Chicago > IT Services > Accounts, Identity, & Security

Using LDAP Affiliations for Authorization

This article explains the various LDAP affiliations used at the University of Chicago.

The University LDAP directory includes a number attributes which are of use in restricting online resources to particular segments of the community. The most broadly useful of these is eduPersonAffiliation, a multi-valued attribute which displays how an individual is affiliated with the University at the most general level. However, because it's so general, and because different affiliations can fade into each other in unexpected ways, it can sometimes be a challenge to determine which affiliations you need to include to get the community you want. This page attempts to mitigate some of this challenge, first by describing the possible affiliations, then by providing examples for some of the most common use cases.

A side note here... When restricting resources by affiliation, it is important to use the eduPersonAffiliation attribute, and NOT eduPersonPrimaryAffiliation. The latter is single-valued and assigns a semi-arbitrary precedence to possible affiliations. As a result, a full-time staff member who is taking a single course part-time will show up with an eduPersonPrimaryAffiliation of student, even though, for most everyday purposes, most people would regard their "primary" affiliation as staff. The eduPersonAffiliation attribute, by contrast, will include both student and staff affiliations.

Values for eduPersonAffiliation

The three "core" affiliations that most people think about are student, faculty, and staff. There are quite a few more potential affiliations, however, and they are all presented here in alphabetical order. The specific relationship between affiliations can be complicated, so it's probably a good idea to read through the whole list if you want a solid grasp on how it all fits together. Be sure to remember that it's possible to have more than one affiliation; all faculty and students, for example, have at least two affiliations, as do most alumni. Three or four affiliations is not unusual, and five or six is not unknown.

academic

The academic affiliation covers anyone who is teaching a course, but does not have a full faculty appointment. This can include graduate students with teaching jobs, graduate students with Teaching Assistant positions, and full-time or part-time lecturers. Note that, since most academic appointments are paid positions, someone with this affiliation will typically also have the staff affiliation; however, this is not always the case. (For example, an academic who is not teaching in a given quarter will not show up as staff, but may maintain the academic affiliation if their department has made appropriate arrangements with the Provost's Office.)

The Office of the Provost approves and maintains academic appointments, and is therefore the source of authority for the academic affiliation. Additionally, Trusted Agents in the various academic and administrative divisions can act as a short-term source of authority for the academic affiliation for new academics who have not yet appeared in the Provost feed.

affiliate

The University maintains relationships with a large number of other organizations. Some of these relationships are close enough to require that some members of these organizations be granted access to resources on the University network. Typically, this requirement is spelled out in the contracts which define the University's relationship with these entities. Examples include (but are not limited to) NORC, the Toyota Technical Institute, and the various Campus Ministries. When these individuals are granted access to the network, they are given an eduPersonAffiliation of affiliate.

Additionally, there are some individuals who have a very close affiliation to the University, but are not formally on the payroll - the University Trustees, for example. These individuals also show up as affiliate.

Two more things to note about affiliate:

  • First, there are some individuals at the University (usually faculty) who may have membership of an affiliated organization alongside their "primary" University affiliation; the affiliate affiliation is in no way exclusive of other affiliations.
  • Second, by definition, the affiliate affiliation by itself gives you no information about which organization an individual is affiliated through; if you want to grant access to all affiliates in Organization A, but not those in Organization B, you can't do it using just the eduPersonAffiliation attribute. (This is true for all affiliations, but because of the diverse sources for the affiliate affiliation, it's especially important to bear in mind here.)

There is no single source for the affiliate affiliation. Rather, there are a number of "small feeds", each containing information about one or more affiliated organizations.

alum

The alum affiliation is attached to anyone who has been granted a degree by the University, or who has been granted equivalent status by the Office of Alumni Development. Note that being granted a degree implies having taken classes here, so anyone with the alum affiliation will typically also have the former_student affiliation.

The Office of Alumni Development maintains the full record of University alumni, and is therefore the source of authority for the alum affiliation.

emeritus

Retired faculty who have been granted Emeritus status by the University retain their network access privileges; they are denoted in LDAP with the affiliation emeritus. Note that, since faculty often have many roles and affiliations with the University, retiring as faculty does not necessarily mean retiring entirely; as a result, individuals tagged as emeritus may still have affiliations as staff or affiliate.

The Office of the Provost approves and maintains Emeritus appointments, and is therefore the source of authority for the emeritus affiliation.

faculty

Any individual at the University who has formally been granted an assistant, associate, or full professorship at the University is tagged with the faculty affiliation. This includes tenured, tenure-track, and non-tenure-track appointments. Note that, since faculty are on the University payroll, they will also have the staff affiliation. Some other things to note:

  • The faculty affiliation does not include everyone in a teaching role at the University. There are many classes taught by non-faculty; see academic.
  • Many doctors in the University Medical Center are also teaching or research faculty, and therefore are listed with a faculty affiliation. However, doctors who are observing their residency are explicitly not in a teaching or research position, and do not have this affiliation.

The Office of the Provost approves and maintains faculty appointments, and is therefore the source of authority for the faculty affiliation. Additionally, Trusted Agents in the various academic and administrative divisions can act as a short-term source of authority for the faculty affiliation for new faculty who have not yet appeared in the Provost feed.

former_student

Anyone who has been admitted to the University and enrolled for at least one course in a degree-granting or for-credit program of study is identified in LDAP as a former_student. Note that completing a course is not a requirement for this affiliation; hence anyone with a student or new student affiliation will automatically also have a former_student affiliation. Likewise, anyone with the alum affiliation will, in all likelihood, have been admitted at some point and therefore also have a former_student affiliation. However, a student who leaves the University without completing a degree-granting program of study, or who goes on a long-term leave of absence, may appear in LDAP with no affiliation other than former_student.

The Office of the Registrar maintains all records for student course enrollment, and is therefore the source of authority for the former_student affiliation.

graham_student

Students of the Graham School of General Studies are identified in LDAP with the affiliation graham_student. The Graham School is the authority for this affiliation.

hospital

Staff of the University Medical Center are identified in LDAP with the affiliation hospital. This includes nurses, residents, housestaff, and medical fellows. Note that, as a general rule, anyone with the hospital affiliation will not have a CNetID; however, they can still authenticate to University network resources using their UCHADid (their login/password for the UCH Active Directory system). However, if they have obtained a CNetID due to some other affiliation with the University, they must use that instead.

Note also that, as a general rule, individuals with the hospital affiliation will not have a staff affiliation.

The University Medical Center maintains the official record of Medical Center staff, and is therefore the source of authority for the hospital affiliation.

lab_school

This affiliation is deprecated and no longer exists in LDAP; it should not be used. See lab_student.

lab_student

Students of the University of Chicago Laboratory School in the sixth grade and older are granted CNetIDs in order to access the University wireless network. These students are identified with the affiliation lab_student.

Note that, since the Lab School does not have degree-granting or for-credit programs at the University level, Lab School students will not have a student, former_student, or alum affiliation. Also note that staff and teachers of the Lab School are staff of the University, and therefore identified with the affiliation staff.

The lab_student affiliation supersedes and replaces the deprecated lab_school affiliation.

The University of Chicago Laboratory School maintains the official record of its student body, and is therefore the source of authority for the lab_student affiliation.

medical_associate

The University of Chicago Medical Center maintains close affiliations with a number of other medical organizations. In some cases, these affiliations are contractually close enough that physicians from these organizations become eligible for CNetIDs. These individuals are identified in LDAP with the affiliation medical_associate. Note that, as a general rule, people with a medical_associate affiliation will not be on the Medical Center or University payroll, and will therefore not have the hospital affiliation you might otherwise expect.

At present time, the only individuals eligible for this affiliation are physicians in the NorthShore University HealthSystem.

new student

Individuals who have been admitted to a degree-granting or for-credit program of study at the University, but have not yet matriculated, are granted CNetIDs with the affiliation new student. This affiliation exists because there are a small number of resources which cannot be made available to students before they actually matriculate. It is replaced by the student affiliation once the new student actually starts taking classes.

Note that anyone with the new student affiliation will also have a former_student affiliation, since they have been admitted to a degree-granting or for-credit program.

For legacy reasons, new student is the only affiliation which has a space in it. If you need to grant access to someone via this affiliation, make sure to quote it appropriately.

The Office of the Registrar maintains all records for student course enrollment, and is therefore the source of authority for the new student affiliation.

postdoc

Individuals engaged in post-doctoral research at the University are granted the affiliation postdoc. Note that post-doctoral positions do not involve taking classes or working towards a degree program, so someone with a postdoc affiliation is highly unlikely to also have a student affiliation. However, since postdocs are on the University payroll, they will always have a staff affiliation.

The Office of the Provost approves and maintains postdoc appointments, and is therefore the source of authority for the postdoc affiliation.

staff

All University staff who are paid off core University budgets are given the affiliation staff. This includes all variations of staff: full-time and part-time, salaried and hourly, exempt and non-exempt, benefits-eligible and non-benefits-eligible. It does not include consultants or short-term temporary staff (see temporary). Additionally, most staff of the Medical Center are not paid off core University budgets, and will therefore not have staff affiliation (see hospital).

Note that anyone with a faculty or postdoc affiliation is on the University payroll, and will therefore also have a staff affiliation. Note also that students with part-time jobs on campus (including work-study positions) are on the University payroll, and will therefore have both student and staff affiliations.

University Human Resources Management maintains the records for all current staff of the University, and is therefore the source of authority for the staff affiliation. Additionally, Trusted Agents in the various academic and administrative divisions can act as a short-term source of authority for the staff affiliation for new faculty who have not yet appeared in the Human Resources feed.

student

All individuals who are registered for classes in degree-granting or for-credit programs of study during the current quarter are listed in LDAP with the affiliation student. Additionally, in most cases, the student affiliation will continue to be associated with an individual for up to two quarters after a quarter in which they took a class; this is done to ensure continued service over the Summer Quarter and single-quarter leaves of absence.

Note that students with part-time jobs on campus (including work-study positions) are on the University payroll, and will therefore have both student and staff affiliations. Similarly, a full-time staff member of the University who is enrolled in a part-time evening or weekend program will also have both student and staff affiliations.

Note also that, since students have by definition been admitted to the University, anyone with a student affiliation will also have a former_student affiliation.

The Office of the Registrar maintains all records for student course enrollment, and is therefore the source of authority for the student affiliation.

temporary

The temporary affiliation is assigned to individuals who do not have a long-term affiliation of the University. It is intended to be used for consultants, short-term temporary staff, and short-term visitors who need access to specific local resources during their time here (e.g. a visiting researcher from another school who needs wireless access). At present time, the temporary affiliation is only assigned to temporary CNetIDs (which all have the format t-Nxxxxx, where N is a digit and xxxxx is either a random string of characters or part of user's name). Anyone with a temporary affiliation will, by definition, not have any other affiliations.

Temporary CNetIDs (and therefore temporary affiliations) are granted by Trusted Agents in the various academic and administrative division; each Trusted Agent is the source of authority for temporary affiliations in his or her area.

Examples of Common Authorization Restrictions

The most important thing to remember when restricting access by eduPersonAffiliation is that they are very, very general. You can't tell if someone is an undergraduate or a graduate student by the student affiliation alone. You can't tell if someone is management or non-management using only the staff affiliation. You can't tell if a professor is in the Humanities Division or the Booth School of Business based solely on their faculty affiliation. In the case of affiliate and temporary, you really have no idea of the user's precise affiliation with the University at all.

So, as a rule of thumb, the more narrowly you need to define access, the more likely it is that you will need to use something other than eduPersonAffiliation for authorization.

With that in mind, the following examples are the general high-level possibilities: All Students, All Faculty, All Staff, All Alumni, and Everybody. Each of these has an obvious answer, but actually requires more thought than is at first apparent.

All Students

This one is pretty straightforward: You can use the student affiliation and be most of the way there.

In practice, however, some departments treat post-doctoral positions as if they were "continuing education". This isn't the "official" University view, but it does mean that for some purposes, you may want to add postdoc to your list of affiliations.

All Staff

Moving up to the next level... The baseline for "All Staff" is, obviously, the staff affiliation.

However, you should remember that many people with the academic affiliation have recurring appointments: They teach a course one quarter each year, and are only paid during that quarter (and therefore only have a staff affiliation during that quarter). If you want to include these people even during their "off" quarters, you need to include the academic affiliation.

Also, remember that Medical Center staff are not paid from the core University budget, and therefore do not have a staff affiliation. If you truly want all staff at the University, you need to include the hospital affiliation.

You may also want to carefully consider the affiliate and temporary affiliations. People with these affiliations are, by definition, not staff of the University; however, for many functions, many affiliates and temporaries act in staff roles, or need to interact with specific systems as if they were staff. You may, therefore, want to include one or both of these affiliations on your "all staff" list - or you may prefer to add some specific individuals to your list, alongside the baseline staff affiliation, to cover a few affiliates or temporaries who need to use your system.

All Faculty

The baseline for a restriction to all faculty is, of course, faculty. This will give access to everyone with an actual professorial appointment.

Beyond that: If you want not only professors, but anyone who is teaching a course, you should also allow in the academic affiliation. If you want to make sure all research-related Ph.D.s are included, you should allow the postdoc affiliation. If you are looking at the larger "community of faculty", rather than "current appointed faculty", you may want to consider adding in those with emeritus status.

All Alumni

Before trying to give access to "all alumni", you really have to ask yourself what you mean by "alumni". Within LDAP, there are two groups that might fit the bill. Alumni "proper" (as identified by the alum affiliation) have completed degree-granting programs at the University and been awarded a degree (or have been granted equivalent status by the Office of Alumni Development). And former students (as identified by the former_student affiliation) have been admitted to the University, but may or may not have earned their degree - they may still be attending classes, or they may have dropped out without ever completing a single course.

If you are targeting a service towards those members of the University who have actually earned degrees, then you should restrict it to alum. On the other hand, if you are trying to display or gather records having to do with attending school here, and the important thing is that they attended school here (regardless of whether they earned a degree), it may be more appropriate to use former_student.

Everyone

Giving everyone access at first seems the most trivial case - you can do this by just using a simple CNet authentication, without ever checking any other attribute at all. However, before doing this, you should consider that it may admit more people than you really want:

  • For administrative reasons, users who have left the university will have no values for eduPersonAffiliation at all - but the will still be able to authenticate. If you don't check for an eduPersonAffiliation, then, you will be allowing in these no longer here accounts, which may belong to people who no longer have any affiliation with the University at all.
  • The affiliate affiliation is typically associated with people who are not in any way employed by the University, but instead gain access to some services thanks to their employer's association with us. A similar situation exists with people in the medical_associate affiliation. Many people with the temporary affiliation are even more tenuously attached to the University. If the service you are bringing up contains sensitive information, or is licensed based on some kind of formal University headcount, you need to consider whether people with these affiliations should really be granted access to it.
  • Although alumni are an important part of the larger University community, they are not actual members of the University in the eyes of the government or in the eyes of most vendors. If you are providing a service which needs to be restricted to the University for legal or licensing reasons, you should carefully review whether the affiliations alum and former_student should be granted access.
  • Students in the Laboratory School have accounts in the University LDAP system, with affiliation lab_student. Depending on the nature of your service, there may be legal (or practical) ramifications to allowing minors access to it.

After working through the likely exclusions, a reasonable basis for "everyone" actually translates into "restrict access to two affiliations: student and staff." Since the faculty and postdoc affiliations are both subsets of staff, student and staff actually grant access to everyone with a current, close affiliation to the University at any given time. (Of course, there's no harm in adding in faculty and postdoc if that makes it easier for you to grasp what's going on; they're just redundant.)

Starting, then, with just student and staff, you may wish to add in a few more affiliations depending on your exact audience:

  • Since people with the academic affiliation only show up as staff during quarters when they actually teach, you may wish to add this affiliation to your list if you want them to have access during the rest of the year.
  • If you want admitted students to have access before they actually arrive on campus, you should add new student.
  • Depending on the nature of the service, you may want to consider adding emeritus or hospital affiliations.

As a general rule, adding in any affiliations beyond student, staff, faculty, postdoc, academic, new student, emeritus, and hospital should be examined very closely. It will usually be more appropriate to grant access to specific members of other affiliations than to the affiliation as a whole.




Keywords:edu_Person_Affiliation, edu_Person_Primary_Affiliation   Doc ID:16191
Owner:Dave L.Group:University of Chicago
Created:2010-12-08 19:00 CDTUpdated:2017-05-22 09:50 CDT
Sites:University of Chicago, University of Chicago - Sandbox
Feedback:  3   0