ITAG - Information Technology Architecture Group

ITAG Architectural Guidelines: Identity and Authorization

MIT Certificates, Kerberos credentials and MITIDs SHOULD NOT be used to indicate membership in the MIT community.

A wide variety of people may have MIT certificates, Kerberos credentials, and MIT IDs. The population that may have these is not limited to MIT faculty staff and students. The population that may posses these identifiers also includes sponsored guests, recent alum, contractors, spouses and dependants, and other affiliates.

Although an MIT certificate or Kerberos credential provides a secure method for a user to authenticate to your system, you system should make an authorization decision about what level of privilege to grant to each user based on additional information.

For more information about sponsoring a guest account, including eligibility requirements please see http://web.mit.edu/accounts/www/guest.html.

The following diagram may give you a better idea of how MIT IDs and Kerberos principals relate to the MIT population. The numbers are from data gathered early in 2005.

Usernames SHOULD be consistent across systems.

• Users SHOULD NOT be assigned a different username than their Kerberos principal.

Not all systems use Kerberos authentication or MIT certificates today. However, history has shown that many applications and systems that have not initially supported these authentication technologies have added the support at a later time. It is much easier to make this migration if the systems are using the same naming conventions prior to the migration.

Even if you believe that your system will never use a common authentication technology, if your system is receiving any data feeds from other systems at MIT, you are likely to greatly reduce your maintenance costs by using consistent user names across all MIT systems.

You may obtain data feeds that provide all of the Kerberos usernames and MIT ID numbers for your systems from the MIT Data Warehouse. Optionally you may obtain some data feeds from the Moira system, but in most cases the Data Warehouse is a preferred source of information.

For more information about the MIT Data Warehouse please see http://web.mit.edu/warehouse/.

Systems that need to restrict access MUST implement some form of authorization.
Simply authenticating a user via Kerberos or a user certificate is rarely provides sufficient information needed to make an authorization decision because of the broad range of people that can legitimately obtain such credentials. Authorization decisions can be implemented in many ways.

Most applications implement an internal mechanism or they use a mechanism exposed by the host operating system. One of the most common methods is the use of simple access control lists (ACLs). Another method is to use the MIT Roles DataBase.

The MIT Moira system is used to maintain list and group information across many systems today. It contains information that is used to populate the AFS PTS servers, Active Directory, and Stellar.

http://web.mit.edu/accounts/www/list.html provides a link to a self service application which will enable you to create new Moira lists which can be used as ACLs within other systems.

https://ca.mit.edu/moira/index.jhtml provides a self service application through which you can modify list memberships if you have the appropriate privileges.

Bulk data feeds of these existing lists and groups can often be arranged for the needs of your particular system. More information about Moira can be obtained by contacting the Moira mailing list at MIT.EDU. If you want to discuss integrating Moira data into your system, or need some developer support please contact isda-developer-inquiry at MIT.EDU.

Bulk data feeds from the Roles DB can also be arranged for your system. Please see the information below about the Roles DB.

In the future IS&T will offer a service that easily lets developers determine if a username is associated with someone that is

• a current full time employee or faculty member
• a current student
• an admitted student
• a sponsored guest account
• Alumni, or
• other affiliation

At this time, you can determine if a user is

1. a current full time employee or faculty member
2. a current student
3. some how affiliated with MIT

More information about how to do that, including demos and sample source code in Perl, Python, and PHP is available at http://mit.edu/pbh/web_scripts/ldap/community-p.html. You may also send mail to isda-devloper-inquiryat MIT.EDU if you have additional questions about this service.
 

Authorization SHOULD be controlled by the central authorization system (Roles).
The Roles Database provides a consistent way to store and maintain access rules for other applications, such as SAP. Authorizations are stored in the Roles system's central database. The Roles Database does not enforce the access rules that it maintains. It only collects the information and distributes it to the appropriate applications, usually as a nightly data feed. Applications with an interface to the Roles Database interpret the access rules from the Roles Database and enforce them.

The Roles Database groups business functions and authorizations into Function Categories, which usually correspond to applications at MIT, such as SAP, NIMBUS, Graduate Admissions, etc. Authorizations in a Function Category may apply to more than one application; for example, financial reporting authorizations in the SAP category apply both to SAP R3 and the Data Warehouse.

The Role Database will continue to evolve. More information about the Roles Database can be found at http://web.mit.edu/rolesdb/www/roleshome.html.

If you need help integrating data from the Roles DB into your system please contact isda-developer-inquiry at MIT.EDU.

Access control SHOULD NOT be based on IP address.
During the early 1990s many systems were implemented which based their authorization decision on the source IP address of the machine connecting to the service. In other words any source IP address with a net 18 address was considered acceptable and other IP addresses were forbidden. This was never a good idea but is now considered a very poor practice for several reasons.

Proxy systems and IP tunnels may exist on campus which enable an off campus user to appear to be originating from a net 18 address.

MIT users may be working from anywhere in the world. They may be on campus, or in a Starbucks just down the street. They may be on a research ship at sea connecting via a satellite link or visiting a research station in the Antarctic. Typically the location of the user should not determine their level of access. Access should typically be determined by the user’s privileges.

If you have a system that performs access control based on the source IP address of the connecting machine please contact isda-developer-inquiry at MIT.EDU.