Skip navigation.
Home

Standards and Policies

Browser Evaluation Criteria

Standards and Policies | Browser Standards

These are the browser evaluation criteria to be used for current and future analysis. Criteria are arranged in broad categories, based on principles. Within each group is a definition of the category, and a measurable or qualitative evaluation method. These are in no particular order.

  • Adoption – support those browsers which are widely used, and those with a significantly increasing adoption rate

  • Application Future – application roadmap and health of the software company or developer community to achieve continued success

  • Security - browser security is a result of excellent design, quick response, and user communication

  • Standards Compliance - how well a web browser implements the World Wide Web Consortium (W3C) published standards and guidelines is directly related to its ability to access current and future web resources

  • Supportability – applications which score well in these categories are easier to support: ease of installation, ease of use, documentation availability, frequent bug fixes, support options, stability, performance, and extensibility

 

 

IMT Supported Browsers

Standards and Policies | Browser Standards

List of currently supported browsers by IMT

 

Windows XP

  • Internet Explorer
  • Netscape

Mac OS X

  • Internet Explorer
  • Netscape

Proposed list of IMT supported Browsers (Fall 2005)

 

Windows XP

  • Internet Explorer
  • Mozilla Firefox

Mac OS X

  • Safari
  • Mozilla Firefox

Web Browser Standards

Standards and Policies | Browser Standards

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.

Standards and Policies

Standards and Policies
This the place for policy and procedure creation, standards formation, that the AWG is asked to participate in. None of these policies are final or authoritative, but works in progress.
XML feed