|
|
|
General: |
UH Metadirectory AttributesAll UH metadirectory attributes have the exact same name as their LDAP counterparts. This document is an alphabetical reference for all metadirectory attributes. Please refer to the UH Metadirectory Information Model to understand the object classes that are defined using these attributes. Alphabetical List
eduPersonAffiliationAlso known as classification. It is a role that a person plays at an organization. It is the same attribute defined by Internet2's eduPerson schema. The allowed values for the University of Hawaii are: Incarnations:
Format: Only the following values are allowed:
*LDAP currently does not differentiate between graduate and undergraduate students, nor between regular and "other" type of staff, faculty or students. The UH Metadirectory does differentiate between the aforementioned subcategories. Obsolete: This eduPersonAffiliation attribute replaces the classification concept defined by UH Directory Services Synchronization Specifications. From now on, the word "classifications" refers to eduPersonAffiliation as defined here. There are two important changes:
Design note: Need to discuss use of admitted, accepted, registered, and enrolled (paid) functions. Should they be classification changes instead of functions? Please refer to the uhOrgAffiliation object class to understand the model used to describe affiliations. eduPersonNicknameDefinition: An authorized person can set this attribute with a bona fide nickname that could be searched on or displayed. This is usually done for individuals who are often known by their nickname as opposed to their legal first name. It is the same attribute defined by Internet2's eduPerson schema. Incarnations:
Format: Any officially verified nickname. Format is same as <uhOfficialGivenName>. Example: Chuck is the nickname for Charles Smith eduPersonOrgDNDefinition: An organization with ties to the University. It is the organization that a person belongs to; in more general terms, it is the organization that a person is affiliated with. Note that there is no information about the relationship between the organizations entered into this attribute (no hierarchy of college, department, and group). This is the same attribute defined by Internet2's eduPerson schema. Incarnations:
Format: Only the following values are allowed:
Obsolete: This eduPersonOrgDN attribute is the same as ORG as defined by the UH Directory Services Synchronization Specifications. From now on, the word "organization" refers to eduPersonOrgDN as defined here. We no longer support the free-form entry of organization names that Unison1 allowed. Such entries should be cleaned out when converting from Unison1 to the UH Metadirectory. Only the allowed values listed above should be used from now on. uhAffEndDefinition: The date and time in which a particular uhOrgAffiliation ends. In other words, the date and time at which this particular University relationship should be deemed obsolete unless that same relationship reappears in subsequent data deliveries. Please refer to the uhOrgAffiliation object class to understand the model used to describe affiliations. Incarnations:
Format: YYYYMMDDTHHMMSS (Follows ISO 8061 specifications, so this means our time zone) Example: 19840315T234530 represents March 15, 1984 at 11:45:30 PM, local time uhAffIDDefinition: A string that uniquely identifies an uhOrgAffiliation entry. Note that an affiliation is also uniquely identified by the following combination: uhUuid + uhDataOrigin + eduPersonOrgDN + eduPersonAffiliation Please refer to the uhOrgAffiliation object class to understand the model used to describe affiliations. Incarnations:
Format: A positive number no longer than 15 digits Example: 234523 uhAffStartDefinition: The date and time in which a particular uhOrgAffiliation begins. Sometimes, an affiliation started so long ago that the actual start date is unknown. In those cases, a best guess may be entered. This attribute is required mainly because we need to know whether an affiliation already started or is in the future. Please refer to the uhOrgAffiliation object class to understand the model used to describe affiliations. Incarnations:
Format: YYYYMMDDTHHMMSS (Follows ISO 8061 specifications, so this means our time zone) Example: 19830315T234530 represents March 15, 1983 at 11:45:30 PM, local time uhAllowedServiceDefinition: A service that a person is allowed to use. Please refer to the uhPermission object class to understand the model used to allow/disallow services to a person. Incarnations:
Format: Only the following values are allowed:
Design note: These values need some work; they are in all likelihood incomplete and the actual values may change depending on whether it's a Metadirectory, LDAP or Database value uhApprovedByDefinition: The uhUuid of the person who approves something. Incarnations:
uhDOBDayuhDOBMonthuhDOBYearDefinition: The day, month, and year respectively in which the person was born. Note that LDAP combines all three as one attribute named uhDOB. The metadirectory treats each uhDOB component separately because regulations may restrict the use of a complete date of birth. Incarnations:
Format: uhDOBYear is not abbreviated (e.g. 1984 is expected as 1984, not as 84); uhDOBMonth is 1 through 12, and uhDOBDay is 1 through 31 depending on the month and whether it's a leap year. In LDAP, the format for uhDOB is mm/dd/yyyy. Example: Obsolete: These attributes represent date of birth components and supersede DOB as defined by the UH Directory Services Synchronization Specifications. uhDataOriginDefinition:Who provided data for a person. Many of its allowed values are also in <eduPersonOrgDN> This is because the organization that provided the data for a person is often the same organization that the person is affiliated with. For example, KCC is the source of data for its own students (uhDataOrigin=kcc, eduPersonOrgDN=kcc). It is also perfectly normal for uhDataOrigin and eduPersonOrgDN to be different. For example, PeopleSoft is the source of data for a KCC faculty member (uhDataOrigin=hris, eduPersonOrgDN=kcc). Another way to think about the difference is:
Incarnations:
Format: Only the following values are allowed:
*These variations of isis might be better modeled via a classification (eduPersonAffiliation) change Please refer to the uhOrgAffiliation object class to understand the crucial role that uhDataOrigin and data delivery frequency play in determining someone's affiliation with the University. Obsolete: This uhDataOrigin attribute replaces DATAORIGIN as defined by the UH Directory Services Synchronization Specifications. uhDisallowedServiceDefinition: A service that a person is not allowed to use. Please refer to the uhPermission object class to understand the model used to allow/disallow services to a person. Incarnations:
Format: Same as uhDisallowedService uhMatchConfidenceOfDOBDefinition: This is not an attribute per se; the metadirectory includes it as an attribute for entries that matched a search criteria. The higher the percentage number, the more confident we are that the date of birth specified by the search matches the date of birth associated with this entry. Incarnations:
Format: Only the following values are allowed:
Design note: we should also account for partial matches and typos. For example, looking for a John Smith born on 10/15/1982 returns a John Smith born on 10/16/1982. This date of birth match does not deserve a value of 0 just because they are not the same date. It's off by one digit, so a value like 90% would be more appropriate. uhMatchConfidenceOfNameDefinition: This is not an attribute per se; the metadirectory includes it as an attribute for entries that matched a search criteria. The higher the percentage number, the more confident we are that the names specified by the search matches the names associated with this entry. Incarnations:
Format: An integer from 0 to 100 where 0 means that the searched and returned names absolutely do not match, and 100 means the most confidence that the searched and returned names are the same. uhMatchConfidenceOfSSNDefinition: This is not an attribute per se; the metadirectory includes it as an attribute for entries that matched a search criteria. The higher the percentage number, the more confident we are that the Social Security Number specified by the search matches the Social Security Number associated with this entry. Incarnations:
Format: Only the following values are allowed:
Design note: we should also account for partial matches and typos. For example, looking for a John Smith whose SSN is 123-45-6789 returns a John Smith whose SSN is 123-46-6789. This SSN match does not deserve a value of 0 just because they are not the same SSN. It's off by one digit, so a value like 90% would be more appropriate. uhNameSubstringsDefinition: This is not an attribute per se; it is useful for searching by name where the actual name components are either not important or unclear. Instead of search specifically for first, middle and last name, this attribute allows us to search for any person whose name contains all the substrings specified in this special attribute. Incarnations:
Format: Substrings must be separated by a space; each substring must have only letters. Example: <uhNameSubstrings>John Smith</uhNameSubstrings> will allow us to search for people whose name includes both substrings: John Walters-Smith, Johnny G. Smith, and Smithers Johnson. Design note: Do we use LDAP's wildcard characters to make name substring searches more useful? Is the search case sensitive? These issues should be resolved as we refine the metadirectory's search command. uhOfficialGivenNameuhOfficialMiddleNameuhOfficialNameSuffixuhOfficialSurnameDefinition: The person's legal first, middle, generation and last names, respectively. Middle initials are acceptable if the full middle name is unavailable. uhOfficialNameSuffix refers to generation names such as III and Jr. These attributes cannot be self-modified. A person must go to an "authoritative" source such as the Admissions Office or their Personnel Officer to change any of this information. Incarnations:
Format: Design note: Internally, we might need to store two versions of the above attributes: one that retains the original format which is not suitable for searching, and another that reduces names to just capital letters and spaces for optimum search results. Design note: What about the short LDAP attributes such as sn, givenName, initials and "compound" attributes such as cn and displayName? Storage Format A: This format retains the original format of the name including case and punctuation, but it must also be in a valid Data Entry Format. If the data provider does not track the proper capitalization of names, it should provide the data in all uppercase instead of applying a name capitalization algorithm that may not always be accurate. All-lowercase or all-uppercase entries are saved as all-uppercase. Mixed case entries are saved as is.
Storage Format B: This is the format that is optimized for searching. Only capital letters and spaces are kept after converting names to this format. The metadirectory stores names using the following algorithm:
Data Entry Format: When sending data updates to the metadirectory, these attributes should only contain upper and lowercase letters, white space, periods, commas, dashes, single quotes and backquotes. Anything else is considered an error. Search Filter Format: The case and punctuation of names that appear in a search filter are automatically converted to match the format used by Storage Format B. Search Result Format: This is the format returned by metadirectory searches. For now, it is the same as Storage Format A. Obsolete: The uhOfficialGivenName, uhOfficialMiddleName, uhOfficialSurname, and uhOfficialNameSuffix attributes replace FIRSTNAME, MIDDLENAME, LASTNAME and NAMESUFFIX respectively as defined by the UH Directory Services Synchronization Specifications. uhPermIDDefinition: A string that uniquely identifies a uhPermission entry. Please refer to the uhPermission object class to understand the model used to describe services allowed/disallowed. Format: A positive number no longer than 15 digits Example: 234523 uhPreferredMailDefinition: The email address that a person prefers to make available to others. Incarnations:
Format: Any valid email address Example: John Smith has a jsmith@hawaii.edu email address but prefers to receive email at john.smith@yahoo.com uhPrivEndDefinition: The date and time in which a particular uhPrivacySetting is no longer valid. Please refer to the uhPrivacySetting object class to understand how personal privacy preferences are tracked. Incarnations:
Format: YYYYMMDDTHHMMSS (Follows ISO 8061 specifications, so this means our time zone) Example: 19840315T234530 represents March 15, 1984 at 11:45:30 PM, local time uhPrivIDDefinition: A string that uniquely identifies a uhPrivacySetting entry. Please refer to the uhPrivacySetting object class to understand how personal privacy preferences are tracked. Incarnations:
Format: A positive number no longer than 15 digits Example: 234523 uhPrivStartDefinition: The date and time in which a particular uhPrivacySetting starts. Please refer to the uhPrivacySetting object class to understand how personal privacy preferences are tracked. Incarnations:
Format: YYYYMMDDTHHMMSS (Follows ISO 8061 specifications, so this means our time zone) Example: 19840315T234530 represents March 15, 1984 at 11:45:30 PM, local time uhPrivTypeDefinition: What type of privacy setting or what application is this uhPrivacySetting entry applicable for? Please refer to the uhPrivacySetting object class to understand how personal privacy preferences are tracked. Incarnations:
Format: Only the following values are allowed:
uhPrivValueDefinition: Usually a boolean value for the setting defined in uhPrivType Please refer to the uhPrivacySetting object class to understand how personal privacy preferences are tracked. Incarnations:
uhQuestion1uhQuestion2uhResponse1uhResponse2Definition: Two pairs of questions and answers that people can define and redefine to identify themselves. They are commonly used to change one's forgotten password. Incarnations:
Format: Answers retain their case sensitivity but leading and trailing white space are removed and multiple white space characters are replaced with a single space. Only a predefined list of questions are currently allowed. A perhaps outdated list can be found at http://www.hawaii.edu/help/accounts/accountinfo.html uhSSNDefinition: This is the person's Social Security Number. It is normally unique to each person, but not all people have one. Incarnations:
Format: 9 digits with the customary dashes after the 3rd and 5th digits (i.e. 123-45-6789). Note: SSN validation and validation for temporary SSN assignments must follow additional rules, see table below. These additional rules also help prevent the collision of temporary SSN assignments by UH Manoa and the Community Colleges. The following information is from a memo that the Office of Planning and Policy sent to all the UH Admissions Offices regarding the assignment of temporary SSN's for admissions purposes. The memo is dated 04/23/97. More information on Social Security numbers may be found at http://www.ssa.gov/foia/stateweb.html
uhUsernameStateDefinition: This attribute tells us the current state of a username. See allowed values below. Incarnations:
Format: Only the following values are allowed:
Design note: This attribute has not been defined for LDAP uhUsernameTypeDefinition: This attribute what kind of username this is. The most common distinction is between regular personal accounts and shared group accounts. See allowed values below. Incarnations:
Format: Only the following values are allowed:
Design note: This attribute has not been defined for LDAP uhUuidDefinition: A unique, non-recyclable UH number assigned to each person that passes through UH. It can be verified for typos because the last digit acts as a check digit. This also means that the first seven digits are also unique. Design note: include algorithm for computing check digit and verifying the validity of a uhUuid Incarnations:
Format: 8 digits; no punctuation. No numbers begin with 57 to avoid confusion with Hawaii SSNs. If masking is used, then insert a dash after every 4 digits. Masking is not used by the metadirectory, LDAP or the database. It is external formatting done at the application level. Design note: this is not consistent with the dashes we do require with uhSSN, but it's probably not worth changing it to use dashes at the middleware level. Example: 10001236 is returned by the metadirectory, LDAP and database,but we encourage applications to use 1000-1236 when displaying it on a web page or printing it. uidDefinition: It is the same attribute defined by Internet2's eduPerson schema. It is the username itself, also known as the login, logon or handle. Currently, this attribute represents the ITS Username. Incarnations:
Format: The ITS Username is currently restricted to a minimum of 2 and a maximum of 8 alphanumeric characters all lowercase. Underscores are used but they are discouraged and will probably be discontinued. Example: jsmith is the uid for John Smith userPasswordDefinition: It is the same attribute defined by Internet2's eduPerson schema. It is the password that in conjunction with the uid allows access to a computer system, application or service. In our current implementation, this attribute refers to the password for the ITS Username. Incarnations:
Format: Usually 6 to 8 characters long with at least one special character Example: 1itl#bHN
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||