Rutgers Enterprise Network Management Numbers & LDAP Attributes
Purpose of Naming
The exchange and use of information contained within an LDAP directory requires that information to be represented in a format which all applications to make use of it can understand. To insure such standardization and avoid potential representation conflicts OIT has established a naming convention for attribute names and type definitions for a handful of common attributes.
Attributes must be composed from two components. The first component must be a naming space to identify the authority that named and defined the attribute. The second component uniquely identifies the attribute within the namespace and should be a descriptive tag related to the information the attribute holds.
All attribute names defined by units at Rutgers must contain the string ‘RutgersEdu’ or ‘rutgersEdu’ as appropriate for proper capitalization. (Note that Rutgers sites may legitimately use attributes defined by other entities.) Attributes registered for university wide use will begin with ‘rutgersEdu’. Other attributes must be prefixed with a registered DNS name to segregate the namespace. The primary user of the attribute must own the DNS name from which the attribute is formed. For example, the owner of rulink.rutgers.edu could use rulinkRutgersEdu* for attributes that are local to that context.
Attribute names must be capitalized according to the common convention in use on the internet. This convention uses capitalization to delineate sections of long attribute names. The following rules determine proper capitalization:
- Each section of a name other than the first should begin in a capital.
- The first section should not be capitalized
- Common abbreviations may be fully capitalized unless they are adjacent in which case the first abbreviation must not be fully capitalized to improve readability.
Attribute Data Definitions
The authority that names an attribute must also define its data storage format. Users of a directory will not need to know the definition as LDAP automatically communicates that information when a client uses the attribute. Other directories that desire to hold equivalent attributes will need to be configured for the data format. Such directories must insure that for any given attribute name the data format and OID are equivalent to that used by the main naming authority.
For attributes in the main ‘rutgersEdu’ namespace the naming authority is the Office of the Chief Technology Officer. Names with this prefix must not be used unless defined and registered by such a central authority. Users of fooRutgersEdu are free to register their attributes or not, as they see fit. To simplify maintenance of this web page, if you wish to document your attributes, we suggest putting them on a web page, and sending the URL to firstname.lastname@example.org.
Before defining your own objects and attributes, you may wish to check to see whether appropriate definitions already exist. The first place to start is probably the Internet2/MACE Object Registry. It contains eduPerson, eduOrg, and other sets of objects used by the higher education community. We particularly recommend using the eduPerson and eduOrg definitions where practical. The documents for these objects contain recommendations about how to use attributes defined by Internet standards, as well as new object classes and attributes intended for use by higher education.
Until usage becomes heavy enough that it’s no longer feasible, this web page will be the official registry. Do *NOT* use OIDs within the Rutgers arc, except in the “experimental” subarc, without making sure that your subarc is registered here.
Rutgers has been allocated an OID arc (220.127.116.11.4.1.10962) for use by our institution. OIDs are used by different types of applications, and all of Rutgers has to share one allocation. In order to add some structure (That can be replaced at will) we purpose to split our assignment into three major ARCs. Enterprise will be for official university wide projects. Private will be sub arced for each unit or project that asks. Any unit that asks for an arc is free to become the registry for that arc and assign OIDs from that arc in any manner they see fit. It is expected that attributes of the form fooRutgersEdu* will be given OIDs from the private arc. The experimental arc will be treated in a similar manner as RFC 1918 address space. Any group can feel free to use attributes from this arc. Official services will never use these, so should not conflict. The experimental arc would be useful for Student projects, development or testing, and other short term needs. Because the experimental arc is not coordinated, another project could be using the same OIDs that you are. If this is not acceptable, please request an arc within the private space.
To request an arc, send email to email@example.com.
The following is the current official registry.
Rutgers (18.104.22.168.4.1.10962) Enterprise (22.214.171.124.4.1.10962.1) LDAP Attributes (126.96.36.199.4.1.10962.1.1) rutgersEduRCPID (188.8.131.52.4.1.109184.108.40.206) rutgersEduIID (220.127.116.11.4.1.10918.104.22.168) rutgersEduRUID (22.214.171.124.4.1.109126.96.36.199) LDAP ObjectClasses (188.8.131.52.4.1.10962.1.2) rutgersEduPerson (184.108.40.206.4.1.109220.127.116.11) Security Policies (18.104.22.168.4.1.10962.1.3) SNMP (22.214.171.124.4.1.10962.1.4) Private (126.96.36.199.4.1.10962.2) rulink (188.8.131.52.4.1.10962.2.1) Enterprise Sys & Svcs (184.108.40.206.4.1.10962.2.2) Newark Comp Svcs (220.127.116.11.4.1.10962.2.3) NB Computer Science (18.104.22.168.4.1.10962.2.4) [csRutgersEdu] Experimental (22.214.171.124.4.1.10962.3)
rutgersEduPerson is an auxiliary class for official Rutgers-specific attributes. It is recommended that person entries
have the person, organizationalPerson and inetOrgPerson object classes defined. It is recommended that attributes be used consistently with the eduPerson specification, and that the eduPerson auxiliary class be used if any of those attributes are required.
MAY ( rutgersEduRCPID $ rutgersEduIID $ rutgersEduRUID ))
You should expect that additional attributes will be added to rutgersEduPerson. In particular, any attribute associated with a person that is defined in the Rutgers enterprise attribute arc (126.96.36.199.4.1.10962.1.1) will most likely be added to rutgersEduPerson, unless there is some reason to create a new object class.
Of course attributes in private or experimental subarcs will be named with prefixes appropriate to those arcs, and will normally be members of object classes in the corresponding name spaces. E.g. there might be a rulinkRutgersEduPerson object class, which contains the attributes starting with rulinkRutgersEdu that apply to persons.
- RFC 2252 definition
DESC ‘Rutgers Community Participant ID’
- The Rutgers Community Participant ID
- Must be the official RCPID, as assigned by OIT Administrative Computing Services. If an individual does not have an actual RCPID, this attribute must be omitted. This is a decimal number. The value of this attribute MUST never be presented to users or otherwise displayed in public. Users MUST not be asked to enter it. For the moment, until there is further clarification with ACS, I would say that it MUST not be used outside the University, or presented to any service outside the University.
- The RCPID is a unique, immutable identifier. It is assigned for everyone that appears in one of the official administrative databases. We do not want users to know it, because we do not want to create any situation where they might ask for it to be changed. The RCPID can be used as a field or key by applications within Rutgers that need to refer to individuals. There is currently a question whether it may be used in this way outside the University, because doing so raises privacy issues. There are other approaches that are being evaluated for situations such as verifying that someone is a valid Rutgers student (e.g. Shibboleth).
- rutgersEduRCPID: 24636
- Syntax: INTEGER; Indexing: eq
- RFC 2252 definition
DESC ‘Internal Identifier’
- The Rutgers Internal Identifier
- Must be the official IID, as assigned by OIT Administrative Computing Services. If an individual does not have an actual IID, this attribute must be omitted. For historical reasons, some individuals may have been issued more than one IID. This attribute lists only the current IID. Additional attributes (not currently standardized) may be used for historical IIDs. Here is an example of a typical IID: ABC123. The IID should be entered as uppercase, although matching is case-insensitive. The value of this attribute SHOULD not be presented to users or otherwise displayed in public. Users MUST not be required to enter it. For the moment, until there is further clarification, I would say that it MUST not be used outside the University, or presented to any service outside the University.There are cases where users have been issued additional identifiers that have a syntax similar to the IID, for use in building Kerberos principals. E.g. on some systems privileged staff with an IID of ABC123 have been issued additional Kerberos principals built from ABC123PPP. It is important to note that these are not IIDs, and will not occur in this attribute.
- The IID is a unique, immutable identifier. It is assigned for everyone that appears in one of the official administrative databases. We do not want users to know it, because we do not want to create any situation where they might ask for it to be changed. While there were some problems initially reconciling the RCPID and the IID, we currently believe that there is a one to one mapping between RCPIDs and IIDs. For new users, the IID is generated by OIT Administrative Computing Services, just as the RCPID is.At the moment, applications may use the RCPID and IID for similar purposes. We are taking a slightly weaker line on making the IID public. The IID is currently displayed by the Rutgers Online Directory, while the RCPID is not. This was done to assist in user support, where it is sometimes necessary to have some unique way to refer to a person. However there are problems with making the IID public at all, because it can generate user requests for changing it if their name changes. Thus the appearence of the IID in the Online Directory should be treated as an exception, which may possibly be reversed as a result of a future reexamination of the use of identifiers.The syntax for an IID originally included + signs. That is originally +ABC123+ was an IID, and ABC123 was not. For a number of reasons recent applications have not been doing this, and by now I believe most people regard ABC123 as the IID, and +ABC123+ as a syntax used in generating Kerberos principals from IIDs. Thus this attribute does not have the + signs.
It is possible that in the future the IID may be deprecated in favor of the RCPID. However before doing that, we will need to look more carefully at questions of visibility of identifiers.
- rutgersEduIID: ABC123
- Syntax: directoryString; Indexing: eq
- RFC 2252 definition
DESC ‘Rutgers University Identifier’
- The Rutgers University Identifier
- This is a unique identifier, as assigned by OIT Administrative Computing Services. It is intended to replace the SSN as the primary identifier for many purposes. As of February 2006 it is only defined for students. However it will eventually be defined for faculty and staff as well. At the moment it will exist for everyone in the Student Records Database. This includes past students and applicants, as well as existing students.
- The RUID is a unique, immutable identifier. It is intended to be defined for everyone that appears in one of the official administrative databases. It is a 9-digit number, assigned from ranges that are not used for valid SSNs. It is considered to be semi-public. Thus it may not be used for posting grades, or other applications that would identify confidential information.
- rutgersEduRUID: 123004567
- Syntax: directoryString; Indexing: eq
LDAP implementors may be interested in the following non-obvious facts, which have been determined by experiment.
Most LDAP libraries treat all attributes alike. They return values as strings, and are set up to handle multiple values for
all attributes. (Typically they return arrays of values.) However Microsoft’s code fetches the schema, and treats attributes according to the schema. This may produce unexpected results:
- The ADSI code (pre-.NET) returns arrays only for attributes that are declared as multi-valued. It returns single-valued attributes as simple variables. Implementors may assume that you can define an attribute as being single-valued, and change your mind later if you need multiple values. Unfortunately making this change may break some code that uses ADSI, because suddenly objects that the code expects are strings will turn into arrays of strings.
- The .NET code for handling LDAP requires OID’s to be allocated for all attributes. The Netscape/Sun directory servers consider OID’s to be optional. Most clients don’t use the OID for anything. (Indeed it’s hard to see what a client would use it for.) However the .NET code will refuse to return the value of an attribute whose definition is missing an OID. This should not be an issue with OpenLDAP, as it requires OID’s to be assigned.
Both pre-.NET and .NET seem to work fine with attributes that don’t appear in the schema at all. But we’re not recommending doing this, as it would require you to run your server with schema checking off.