Skip navigation.
Home

Identifiers

APU NetID Guidelines

Standards and Policies | Identifiers | IdM

Background

It is increasingly important that identifiers be made coherent and consistent throughout the enterprise. Many systems use different names for the primary identifier used along with a password to authenticate access to a resource (Login, Logon, Username, Name, UserID etc.). When APU started providing central authentication services, which coincided with the release of the üdeupa portal, we established "üdeupa username and password" as the name of this identifier. With the portal name change, we realize that we need a way to refer to an APU Network Account independent from a particular service. For this reason, as well a desire to adopt higher education standards, we are renaming these identifiers.

Summary

The Central Authentication Service requires an APU Network Account consisting of an APU NetID & Password to verify identity. Any system which makes use of the APU Central Authentication Service, should use "APU Network Account" to refer to the account. "APU NetID" should be used to describe the principle identifier. "APU Network Password" is used to refer to the password explicity if needed. Systems that have the capability of modifying the prompting for these identifiers, should be changed. Over time, all user documentation and communication should be updated as well. We should no longer refer to "Windows Login, or "APU Domain Login", but should use the term "APU NetID".

Change Matrix

Old Title New Title
üdeupa Account APU Network Account
üdeupa Username APU NetID
üdeupa Password APU Network Password
üdeupa Username & Password APU NetID & Password

Use Cases

  1. Centrally Authenticated Services:

    Any service which authenticates against APU Central Authentication Services should state that the service requires an "APU Network Account. Alternately, "APU NetID" may be used to specify the credentials required for a particular service. If password is not explicity stated, APU Network Password is implied by association.

    This service requires an APU Network Account.
    
    or 
    
    Anyone with an APU NetID may use this service.
    
  2. Referring to the APU Network Credentials together:
    APU NetID & Password
    
    or
    
    APU NetID and Password
    
  3. Referring to the APU Network Credentials explicitly:
    APU NetID
    APU Network Password
    
  4. On Login Screens:
    APU NetID: ______________  Password:  ______________
    
    or
    
    APU NetID: ______________
     Password: ______________
    
  5. Non-Centrally Authenticated Services:

    Systems which do not authenticate against the APU Central Authentication Service, should refer to their credentials by the name of their system. Example:

    IFAS Username and IFAS Password
    

    Even if a system's initial username has the same value as the APU NetID, it should not continue to be referred to as APU NetID. Equivalent value is not equivalent title. For example: If a user was activating their account a new system which pre-populated usernames to match APU NetID, they could include the following instructions on first login: "Your IFAS Username is the same as your APU NetID, please select a password." Future logins however, should prompt for "IFAS Username" not "APU NetID". Once exception to this, is a service which may require an APU NetID, but not prompt for a password. Such a service, can continue to prompt for APU NetID. (current example: Link+ Library Loan Service)

Notes

The APU Central Authentication Service does not exclusively refer to our implementation of Yale's CAS, an Open Source application for web authentication. APU CAS refers to the centralized authentication services provided by IMT in order to verify identity of users of primary network resources, portal and workstation access etc. APU CAS is supported by IMT's Identity Management infrastructure, consisting of Microsoft's Active Directory and OpenLDAP.

APU NetID Approved

Identifiers
The proposal to switch from udeupa username to APU NetID has been approved by IMT Cabinet. Please see the Proposal for the impact of this change. The change will be reflected immediately on the new University Portal system, and over time in future documentation efforts.

APU NetID Identifier Directory Considerations

Directories | Identifiers

Part of the reason for choosing NetID is to clear up some confusion around the UID identifier which has two meanings.

On Posix systems such as Unix/Linux, UID refers to User ID. OpenLDAP currently uses the UID attribute for the "Udeupa Username". This will continue to be true even after this "APU NetID" name change.

UID also stands for Unique Identifier. This value appears as the first field in the Distinguished Name (DN) in LDAP. The DN represents the location of a record in the heirarchical Directory Information Tree (DIT). APU is using the same value for both the DN and the attribute. For example:

dn: uid=joestudent,ou=Students,ou=People,dc=apu,dc=edu
uid: joestudent

According to Identifiers, Best Practices for Higher Education, the UID should be distinctly different than the NetID.

This ID is centrally provided, perhaps with distributed online clients. It is assigned to all current active users of campus electronic resources. The UID should be non-revokable and non-reassignable; hence it needs a large capacity (32 bits minimum). All other identifiers should be either directly or indirectly linked to the UID.

The identifier most closely associated with these qualities is our "APU ID Number", not the NetID. The reasons for using a value in the DN that won't change, is because changing the DN is not efficient. It requires, in most cases, removing a persons entire entry and re-adding it. It also requires changing all group memberships for that user, which are associated by DN. The fundamental concept is that an active APU person's DN should never need to be changed. As long as they are affiliated with APU their "LDAP Address" should not change. This is also the reason why the Internet2 Directories Working Group is promoting the use of a "flat" ou=People tree, not desiring to represent affiliation via the person's location in the DIT. A person is rather referenced in groups by their "permanent DN" throughout the directory.

XML feed