Skip to content Accesskey=4Skip to sub-navigation Accesskey=NView our Accessibility Options MIT Information Services and Technology Home About IS&T Contact IS&T Site Map  
Getting StartedGetting Services by Topic or Alphabetically Getting Help

Infrastructure Software Development and Architecture

ISDA logo

 

 Coupling authorization and MIT affiliation

 

One of the guding principals from MIT's ITAG (Information Technology Architecture Group) says, "Systems that need to restrict access MUST implement some form of authorization." To often in the past systems have been created that grant users all privileges once authentication has been performed. This is not a best, or even good, practice. Although ITAG recommends that the majority of authorizations be controlled via the MIT Roles DB there are cases where the appropriate form of control is a users affiliation with MIT.

At the suggestion of ITAG, IS&T has created the necessary data feeds and other infrastructure needed for application developers to easily access affliliation information about a user. An developer can then make an authorization decision based upon that information. Overtime we expect the granualrity of the affiliation data available to increase. For now there are three broad categories that are available to all application developers. The three categories are:

  • Employee (faculty and staff that exist in the HR systems)
  • Students (as defined by the Registrar)
  • Affiliates (people that can authenticate but are not currently defined to be employees or students by HR and the Registrar)

One of the easiest methods for a developer to access the affiliation information is via the LDAP service operated by OIS of IS&T. The links below include sample source code in a small variety of languages for doing this. The demos allow you to execute the sample source code so that you can easily see the results. The demos are executed using the scripts server operated by MIT's SIPB.

Other projects may also desire to evaluate groups that are defined in the LDAP directory. Group memberships cannot be performed when using an anonymous bind to the LDAP directory. At this time you must bind the the LDAP directory using the GSSAPI mechanism. This means that you will not be able to authenticate as the user of your web application because your web server will not have access to the user's Kerberos credentials.

Two sample perl programs are provided demonstrating the use of groups in LDAP. The first, printMembers.pl takes an MIT group name as an argument and will print out the individual members of the group.

The second example code takes a group name and a username and will indicate if the user is a member of the group.

last updated by Paul B. Hill on 1/16/2007