Identity and Access Management

Table of Contents

• Getting Started | Overview | Resources | Standards
• Business Requirements of Access Control (ISO 9.1)
• User Access Management (ISO 9.2)
• User Responsibilities (ISO 9.3)
• Operating System and Application Access Control (ISO 9.4)

Top of page

Overview

A basic element of any institution of higher education's information security program is the protection of information resources that support the critical operations of the institution from unauthorized access, modification, or disclosure. Access control is the use of administrative, physical, or technical security features to manage how users and systems communicate and interact with other information resources.

In its essence, access is the flow of information between an entity requesting access to a resource or data and the resource. The entity can be a device, process, or a user. Access control is any mechanism by which a system grants or revokes the right to access some data, or perform some action. Normally, an entity must first login to the resource using some authentication system. Next, the Access Control mechanism controls what operations the entity may or may not make by comparing the credentials provided to an access control list.

Examples of access control:

• When a user is prompted to provide a username and password to be able to access EDUCAUSE resources (e.g., this guide).
• Upon logging in, the user attempts to Edit a resource (e.g., this guide section) and the user is denied based on the fact that the user is not on a list of users that have the right to edit an EDUCAUSE resource.
• Since the user was denied access, the user requests the appropriate authority to be given rights to edit the resource. Upon verification of membership in an EDUCAUSE Working Group and establishing the business need, the user is added to the list of users that have the right to edit the resource.

The main topics of Access Control are:

Business Requirement for Access Control

1. Access control decisions
   1. Centralized access control
   2. Decentralized access control
2. Access control policy
3. Access control program

User Access Management

1. User type and affiliations
2. User registration
3. Privilege management
4. User password management
5. Review of user access rights

User Responsibilities

1. Password use

System and Application Access Control

1. Operating systems
   1. User identification and authentication
   2. Single sign-on
2. Application and information access control
   1. Information access restriction
   2. Sensitive Information Isolation
   3. Federation
   4. Cloud Computing and Software as a Service (SaaS)
   5. Mobile Computing and Teleworking

Top of page

Business Requirements of Access Control (ISO 9.1)

1. Access Control Decisions

Institutions of higher education create, collect, maintain, and makes available large amounts of information in support of their educational, health care, and research missions. This information is an institutional asset that must be administered and protected in accordance to their value and in conformance with federal, state, and institutional rules and regulations.

Institutional staff, faculty, students, retirees, alumni, prospective students, and members of the community access and utilize different types of information stored on and accessible via institutional systems to perform the numerous tasks required by their respective roles or seek information about programs and services provided by the institution. Examples include:

• Students
  • Learning resources (course management systems, library, etc.)
  • Online student systems
• Staff
  • Employee directory
  • Online human resources systems (timesheets, payroll, benefits, etc.)
• Faculty and Researchers
  • Online course materials and library resources
  • Federal research agencies, funding, and data resources
• Alumni and Donors
  • Email for life
  • Alumni directories and services
• All
  • Student/Employee directory
  • Emergency notification systems

Data owners shall determine, approve and assign the level of access to institutional systems and data based on the responsibilities, job functions, reporting or outreach requirements based on the confidentiality of the data and to the restrictions imposed by federal, state and institutional rules and regulations.

For a list of some of the common business situations in higher education that call for access management solutions see Access Management Use Cases Organized by Area of Interest, EDUCAUSE and Internet2 CAMP(Campus Architecture and Middleware Planning)

The ECAR Identity Management in Higher Education, 2011 Report (Subscription may be required) contains information about motivators and challenges for ID management initiatives, benefits of ID management, funding availability, and key outcomes in five core ID management elements gathered through a survey of 323 higher education institutions in the U.S. and Canada and from interviews with 55 IT leaders at 43 institutions.

The Aegis Identity Survey White Paper - Trends in Identity & Access Management Solutions in Institutions of Higher Education - 2012 contains a detailed analysis of identity and access management technologies as they relate to college and university business drivers and challenges; strategic approaches towards related technology; and the effects of emerging technologies on identity and access management infrastructure.

See Electronic Identity: The Foundation of the Connected Age, an article in EDUCAUSE Review Online Oct. 2013, for an analysis of the increasing importance of trusted electronic identities in the day-to-day business of institutions of higher education.

See Implementing True Identity Management On Your Campus And Planning For Success (And Avoiding Critical Mistakes), a presentation at the EDUCAUSE Conference 2012, for lessons learned from colleagues at Massachusetts College of Art and Design, The George Washington University, and Princeton University.

See Information Security or Identity and Access Management? for an overview of the overlap that exist between information security and IAM and what the University of Massachusetts and the University of Chicago are doing to bridge the gaps that may exist between the two practices.

a. Centralized Access Control

Rather than maintaining separate accounts on each system, some institutions of higher education use a central account database that all systems can authenticate against. In some environments, a Novell server or Windows domain controller functions as the central authentication system. These systems can also be used to enforce policies, limiting users to specifically authorized actions and data. With the increasing number of Web-based services, many institutions are implementing mechanisms to integrate their central authentication systems with their Web-based applications. The JA-SIG Central Authentication Service (CAS) can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate.

Other institutions use Kerberos because it supports a broader range of applications and operating systems. However, because Windows systems work best in a Windows domain, even institutions that use Kerberos generally maintain a Windows domain controller that is synchronized with the accounts in their Kerberos domain.

Lastly, Lightweight Directory Access Protocol (LDAP) is another approach to centralized authentication and authorization that is increasingly used in higher education institutions.

See From Headaches to Happiness with Person Registry, a presentation at the EDUCAUSE conference 2010, for an example of how an institution of higher education created a centralized repository of identity information (person registry) by asking three seemingly simple questions in an environment with multiple internally and externally controlled systems of record: Who are you? Why are you here? What do you want from us?

See Banner Identity Integration with Active Directory, a poster presentation at the EDUCAUSE Conference 2010, for an example of how another institution integrated Banner as the authoritative Enterprise Resource Planning (ERP) system with the institution's Active Directory authentication system to come up with a completely automated single common credential for all institution's constituents.

b. Decentralized Access Control

It is also not uncommon to find institutions of higher education opting for a decentralized or distributed user account databases where the verification of authorization is performed by various entities located throughout the campus. Common disadvantages of decentralized access control systems are that many times are duplicative, require the coordinated work of several teams, and the administrative overhead is high since changes may need to be implemented throughout numerous locations. Often times each location develops into a silo that is maintained by local administrators without the input / coordination of the other teams.

Decentralized access control implementations do have benefits. A well implemented and coordinated distributed system does not have single point of failure. If one access control point fails, others can balance the load until the problem is resolved.

2. Access Control Policy

Access Control policies should clearly communicate the institution's business requirements regarding identification of users, access to institutional information resources, user access rights, and special access privileges and restrictions.  The following could comprise the core of an institutional access control policy framework.

• Roles and responsibilities
  • Need-to-Know:  Access only to information needed to perform assigned tasks.
  • Need-to-Use:  Access only to information resources needed to perform assigned tasks
  • Access levels and privileges by role
  • Periodic review and removal of access levels and privileges
  • Segregation of duties for requesting, authorizing, and reviewing access levels and privileges
• What is required to identify users?
  • Requirement for vetting users in person
  • Requirement to archive records concerning user identification and credentialing
• What criteria is used to determine the types of credentials used?
• What criteria is used to determine the level of access to applications and services?
  • Identification of roles with privileged access
  • Contractual obligations for limiting access granted to vendors and partners
• What is required from identity providers and from service providers?
  • Requirement to identify the security requirements of applications - both, purchased and developed internally
  • Requirement to determine the Level of Authentication (LOA) required to access a service based on risk

The EDUCAUSE Access Control page contains publications, presentations, policies, podcasts, and blogs regarding mechanisms by which a system grants or revokes the right to access some data, or perform some action.

3. Access Control Program

As data, access, and networks continue to expand, institutions have an ever-increasing need to manage identities and access. The optimum solution for this function may be a well-planned and institution-wide IAM program. In its simplest form, IAM ensures that only the right people can access the right services at the right time.

However, within a complex organization, establishing an IAM program is not an easy task. Many stakeholders, technology areas, policies and processes must work together for a scalable and robust IAM Program. In addition, governance plays a key role in the success of any IAM Program and implementation.

A sample IAM Program roadmap for institutions to use in developing an IAM program:

Top of page

User Access Management (ISO 9.2)

1. User Types and Affiliations

Institutions of higher education have a broad constituency with varying degrees of affiliation. One thing in common among all members of an institution's constituency is that all require access to some type of institutional information for a determined period of time - they all become Users.

At a high level, institutions can divide Users into two groups based on their type of affiliation to the institution:

• Formal Affiliation: These are Users whose affiliation to the institution is established by some kind of contract or enrollment. Users in this group include staff members, employee, faculty, researchers, and students.
• Casual Affiliation: These are Users whose affiliation to the institution is transitory, periodic, mostly informational and not established by a contract or enrollment. Users in this group include guests, retirees, donors, parents, library patrons, alumni

Furthermore, a considerable number of Users have multiple affiliations depending on the number of "hats" an individual wears while affiliated to an institution. Examples:

• Administrators with Faculty appointments
• Student Staff
• Staff or Faculty and Parent of Applicant or Student
• Staff and Alumni
• Staff and Employees who are also Students pursuing a degree
• Emeriti Faculty

Lastly, it is important to understand the affiliation life-cycles and User transitions that should inform an institution's User Access Management process. Examples:

• Student → Student/Worker → Employee/Staff/Faculty → Retiree
• Student → Alumni/Donor
• Applicant → Employee/Staff/Faculty → Former employee
• Prospective/Expected User → Active User → Deactivated User → Deleted User

The examples above are one-dimensional and serial. As stated above, many times these can be multi-dimensional and cyclical.

2. User Registration

Identification is the mechanism to ensure that a user, program, or device is the entity it claims to be.

User Registration:

The User registration process has, generally, four steps:

• Identity Vetting: the collection and validation of identity information. This information may include full name as it appears in identity documents, date of birth, current address, existing relationship with institution (e.g, hired employee, enrolled student, etc.
• Identity Proofing – aligning collected data and matching an actual person to it. This can be done either:
  • By leveraging a pre-existing relationship with an individual (e.g., individual was a former student or a former employee)
  • In-person. The individual is required to go to the institutional office charged with User registration and produce a valid current government photo ID that contains the individual's picture (e.g., driver's license or passport) and an address. The office compares the picture to the person, verifies the information with its records and, if everything checks, records the sources of proof and approves the issue of a credential.
  • Remotely. If the individual is unable to fulfill the proofing requirements in-person (e.g., staff in a small satellite campus, researcher in the field in a different country/continent), they can forward to the institutional office charged with User registration, via email, mail, fax, a valid current government ID number (e.g., driver's license or passport) and either a second government ID number or a financial account number (e.g., checking or savings account, credit card) with supporting documentation. The office contacts the corresponding agencies and verifies the information provided with their records, and, if everything checks, records the sources of proof and approves the issue of a credential.
• Creation of a master identity record
• Issuance of credentials - each credential issued shall include a unique identifier (e.g., UserId) that distinguishes it from all other credentials issued to the individual and shall clearly associate the credential unique identifier to the individual's master identity record. Credentials are usually issued as an UserId / Password pair but they can also be imbedded in other devices such as Id Cards, second factor tokens (See Two-Factor Authentication topic below), etc

See UM Community System: Expanding Identity Boundaries for the University of Maryland's approach to establish UM identities to users outside the traditional cam,pus user base (i.e., staff, faculty, students) including volunteers, visiting students, emeritus faculty, contractors, etc and expedite their access to specific information resources.

See IdM/IAM and Remote Student Services: Risk Assessment and Identity Management Practices for a discussion on the link between risk and identity management practices when institutions of higher education offer personalized remote services. From establishing student identity, considering remote identity proofing practices to support higher security access, and credentialing to assessing the institutional risk and level of regulatory compliance.

See Provisioning Remote Users for a discussion of the general challenges of provisioning remote users and the specific impact of HEOA regulatory requirements that ask accrediting organizations to evaluate college identity procedures for distance education students. Presentation Slides

See Identity Verification for the University of Indiana's approach to verify the identity of affiliated individuals including alternatives for verifying an identity when in-person vetting is not an option.

See Centralizing and Automating the Management of Special Identities for the University of Maryland's approach to automate the administration of special accounts. Special accounts are accounts that do not belong to a faculty, staff, or student but to mailing lists, shared mailboxes, applications, guests, etc. From establishing requirements, system characteristics, to benefits and lessons learned.

See CommIT: Simplifying Admissions Identity Management for Georgetown University's way to leverage federate identity management to match electronic records for college applicants and institutions using a single set of user credentials that can be used across various services.

3. Privilege Management

Privilege management is the set of processes for managing the user attributes and policies that determine a user's access rights to an information resource. In other words, what user attributes, job functions, and organizational affiliations can serve as the basis for access authorization decisions. Users should be granted the least privilege - the most restrictive set of permissions or access rights - needed to perform assigned work tasks.

See Privilege Management Recipe for best practices and processes for establishing a privilege management system.

Two common problems related to privilege management are excessive privilege and creeping privilege. The former happens when a user has more access or permissions than the assigned work tasks and/or role requires. The latter happens when a user account accumulates privileges over time as roles and assigned work tasks change. Both problems are addressed by periodic review of user access rights.

Management of Administrative privileges is particularly important since very common cyberattack techniques take advantage of unmanaged administrative privileges. An attacker can trick a user into downloading an application from a malicious website or opening a malicious email attachment which contains executable code that installs and runs on the user's device. In cases where users have administrative rights to their devices, the attacker can take over the device and install keystroke loggers, sniffers, etc. to find administrator passwords and other confidential data. Another common attack involves domain administration privileges in Windows environments potentially giving an attacker significant control over numerous devices and access to the data they contain.

4. Password Management

It is important to realize that people will share their passwords unless you provide them with some other method of allowing specific individuals to access information in their accounts. For instance, individuals in upper management often ask an administrative assistant to check their e-mail. Also, when people go on vacation, they may need to give someone temporary access to data on their computers, in e-mail, and on other systems. Password sharing policies should be put in place along with solutions that provide needed functionality with accountability for the shared resource.

Good Password Practices:

• Use strong passwords or long passphrases
• Do NOT write passwords down
• Do NOT share passwords
• Use different passwords for different applications (e.g., work vs personal; shopping,and banking vs casual email and Facebook; applications that contain confidential information vs those that do not, etc.)

What is a Strong Password?

The strength of a password is determined by some restrictions - like minimum length, password age, use of multiple type and special characters, and reuse restrictions - which determines the average number of guesses an attacker must try to guess the password and ease with which the attacker can test the validity of the guessed password.

Password entropy is a mathematical way to measure the difficulty of guessing or determining a password. As applied to passwords, guessing entropy is the estimate of the average amount of work needed to guess a password. Min-entropy is the measure of difficulty of guessing the easiest single password to guess in the population. Password entropy is expressed in bits.

If a password of k bits is chosen at random there are 2 to the k exponential possible values and the password is said to have k bits of entropy. If a password of length l characters is chosen at random from an alphabet of b characters (e.g., the 94 printable characters on a typical keyboard) then the entropy of the password is b to the l exponential. See the following InCommon Assurance page for Password Entropy Calculators. Most Institutions who are pursuing InCommon Silver are using the The University of Wisconsin calculator.

An example of a reasonable strong password is:

• An attack targeted against the password should have a probability of success of less than 2 to the -14 exponential (i.e., 1 chance in 16,384) over the life of the password.
• Has at least 10 bits of min-entropy
• Has a minimum length of 10 characters
• Does not contain a username, personal name, or institution name
• Avoids repetition or dictionary words
• Contains a mix of upper and lower case alpha characters
• Has at least 2 non-alpha characters (i.e., numerals and/or special characters)
• Has a password life of 90 days
• Has not been used before (i.e., no password reuse)

To Change or Not to Change? How Often?

Again, there are as many answers to these questions as there are information security professionals. The argument for changing passwords regularly is that the longer a password remains the same and the more often the same password is used, then it is more likely that the password will be discovered or compromised. Also, the benefit of an "expiration date" on a password is that it limits the amount of time a lost or compromised password can be used by an unauthorized party. The more secure or sensitive the information resource, the more frequently passwords should be changed.

Conversely, the argument against changing passwords regularly is that strong passwords are reasonably secure and they take longer time and more effort to guess thus making them less likely to be discovered or compromised. Also, it may not be as easy to come up with easy to remember strong password very 30 or 60 days.

Even though there is no "right"or "perfect" answer, the following points are worth considering:

• Password policy should be based on risk, vulnerabilities, and deployed safeguards
• The period of time between changes should be determined by the required strength of the passwords being used
• Password changes makes it harder for users to use the same password for multiple services (i.e., forces password "diversity")
• Periodic password changes, especially when done as a routine, could limit successful phishing attempts since users would know when it is time to change passwords and when it is not.

Password Management Problems: By no means an comprehensive list

• Need (and failure) to remember multiple passwords
• Need (and failure) to remember strong passwords
• Frequency of password change
• Coming up with easy to remember but difficult to hack passwords multiple times per year
• Need to replicate password change to multiple devices or applications
• Sophistication of social engineering and "phishing" attacks

See Passwords, a presentation by Joe St Sauver PhD, Security Programs Manager - Internet2 for a broad discussion on Passwords and related trend, problems, alternatives, and available technologies.

Alternatives to Manage the Password Management Problems::

Passphrases

A passphrase is just a different way of thinking about a "secret" or "something you know". The main difference is that a passphrase is longer. While a usual password is 8 to 10 characters long, a passphrase can be twice as long. Compared to passwords, a passphrase is generally stronger because it is more memorable than passwords thus reducing the need to write them down, they make some types of brute force attacks impractical since they are much longer than passwords, and they make phrase or quote dictionary attacks almost impossible if the passphrase is well constructed. See how the University of Indiana is using Passphrases to enhance information security.

Password Vaults:

See Security Awareness for User Authentication: Passwords and Beyond and Passphrase Vaulting for University of Indiana's use of Password vaults to securely store users' multiple passwords providing users with the capability to remember only one password or passphrase while allowing them to maintain unique passwords across multiple applications.

5. Review of Access Rights

Some data, due to its nature or confidentiality requirements, may be restricted from general access by users and may require additional levels of formal approval before being made available. Users are granted access to these data on a need-to-know basis - when there are justified work-related reasons for access or need to know. An important characteristic of need-to-know access is the the access is granted for a limited period of time. When the reasons for access are no longer valid, access to the data is (or should be) revoked.

Least privilege and need-to-know access underscore the importance of the periodic review of user accounts and their corresponding access rights. Dormant user accounts - active user accounts which show no activity for very long periods of time - poses an unnecessary risk for unauthorized access to confidential data. The periodic review of user accounts and corresponding access rights with system owners, disabling user accounts after a preset period of inactivity, purging them after a longer period of inactivity are all good practices to ensure that a system does not contain old, unused user accounts and to mitigate risk.

Top of page

User Responsibilities (ISO 9.3)

Users should be made aware of their responsibilities towards protecting their issued credentials, choosing strong passwords and keeping them confidential, and preventing the unauthorized disclosure of sensitive information under their care. The following can be included in the institution's Acceptable Use or Information Security Policy. Systems should be locked when left unattended

Users shall

• Access data in order to comply with the duties of their role or job duties on a need to know basis.
• Not attempt to access data or programs contained on systems for which they do not have authorization or consent.
• Not share their computer/network account, password, personal identification number (PIN), digital certificate, security token (i.e. Smartcard), or any other device used for identification and authorization purposes.
• Not share digital certificate passwords used for digital signatures.
• Not circumvent password entry through use of auto logon, application "remember password" features, embedded scripts or hard-coded passwords in client software.
• Password-protect their desktops/laptops when left unattended

Top of page

Operating System and Applications Access Controls (ISO 9.4)

1. Operating System Access Control

a. Authentication

Authentication is the mechanism to confirm the identity of an entity requesting access to an information resource. Authentication is often a prerequisite to allowing access to an information resource. To be properly authenticated, the entity is required to provide credentials - a unique identifier or NetId and a password, passphrase or token. The credentials are compared to the identifying information previously stored on the entity and if the credentials match the stored information, the entity is authenticated.

Most institutions of higher education require all members of their communities to have their own unique username and password to access certain IT resources. In addition, institutions authenticate these individuals before allowing them to connect to the campus network or Internet. This approach not only enables institutions to attribute network activities to individual accounts, it also gives institutions the opportunity to scan systems for vulnerabilities before they connect to the network.

An overview of best practices for identifiers, authentication, and directories is available at http://middleware.internet2.edu/internet2-mi-best-practices-00.html.

The Enterprise Authentication Implementation Roadmap, from the NMI-EDIT consortium, is a recommended approach that can be used by institutes of higher education to build enterprise authentication services to enable appropriate interoperability with peer institutions, the Federal Government, industry, and other partners.

Is a Username and Password Enough for Authentication?

Information security practitioners are increasingly making the case that passwords and password practices are bad and getting worse. Specifically, that usernames and passwords are no longer sufficient to authenticate to information resources containing confidential information. Two-Factor Authentication is the use of an additional factor to minimize the probability of fraudulent authentication.

See this Guide's Two-Factor Authentication page for an overview and technology available. This document describes the use of a second factor in addition to the traditional UserId/password pair to minimize the probability of fraudulent authentication. It touches on the business reasons for using an additional factor, technology available, and a discussion of biometrics.

See Finally, A Two-Factor Solution for the Rest of Us for Penn State's approach to implement two-factor authentication on campus.

See Multi-Factor Authentication: All in This Together, a presentation that describes the activities and progress of the Multi-Factor Authentication (MFA) Cohortium.

b. Single Sign-On

The JA-SIG Central Authentication Service (CAS) can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate. Although having a central authentication system makes account management easier, the exposure of one stolen account is greater when it gives the thief access to multiple systems on the network. Therefore, single sign-on is not necessarily desirable in higher education environments where password theft is a common risk. Less sign-on is ideal - using centralized authentication for most systems but maintaining separate accounts on computer systems that contain particularly sensitive data and require added protection.

See CommIT: Simplifying Admissions Identity Management for Georgetown University's way to leverage federated single sign-on to match electronic records for college applicants and institutions using a single set of user credentials that can be used across various services.

 2. Application and Information Access Control

a. Information Access Restriction

The EDUCAUSE Access Control page contains publications, presentations, policies, podcasts, and blogs regarding mechanisms by which a system grants or revokes the right to access some data, or perform some action.

b. Sensitive System Isolation

Definition: Merriam-Webster defines Segregation as the action or state of setting someone or something apart from other people or things or being set apart.

Information resources that are critical to the performance of an institution of higher education's mission, contain confidential information, or is otherwise considered sensitive should be segregated (i.e., have a dedicated environment) based on sensitivity and risk. The segregation of information resources can be accomplished by:

• Creating network domains (e.g., public vs internal, critical vs non-critical, etc) - collection of devices and subjects that share a common security policy - and trusts - a security bridge between domains to enable users of one domain to access resources from another - are common practices in decentralized access implementations. Domains are defined based on risk and the specific security requirements of the domain.
• Implementing virtual local area networks (VLAN) and/or virtual private networks (VPN) for specific user / application groups
• Controlling network data flows using network equipment routing / switching capabilities (e.g., access control lists (ACLs))

c. Federation

Definition: A federation is an association of organizations that come together to exchange information, as appropriate, about their users and resources in order to enable collaborations and transactions (InCommon.org)

Drivers:

• Increasingly, people must easily and securely exchange information in cyberspace among known individuals and be trusted to access restricted resources without having to struggle with numerous and onerous security processes
• Ideally, individuals would each like a single digital credential that can be securely used to authenticate his or her identity anytime authentication of identity is required to secure any transaction. (William Weems, Ph.D. UT Health Science Center at Houston: Sharing Restricted Resources Across Organizational Boundaries)
• Traditional forms of authentication and authorization are no longer sufficient or the level of assurance needed by modern internet-based applications
  • Increase security
  • Compliance with federal and state rules
• Application security is becoming increasingly onerous (multiple applications, multiple enterprises, and multiple user roles in multiple contexts)
  • Inter-institutional collaboration
  • Operational efficiencies and cost control
• Examples:
  • Institution wants to offer services to their constituents but doesn't want to host them.
  • Vendor wants to offer a service to institutions but doesn't want the burden of managing user credentials and authentication.
  • User wants seamless access to services. "Single Sign-On".
  • Security officer wants to protect University assets, user identity information, and passwords

Traditional Approach:

Federated Approach:

First Steps:

Technically speaking, it involves:

• new policies
• new processes
• new trust relationships
• new authentication and authorization mechanisms
• new enterprise directories
• new applications and much more

Participating organization must agree on:

• Technical specifications: data attributes to exchange, the software to interoperate with
• Policy specifications: privacy, establish trust and trustworthy data

Must provide two sets of services:

• Metadata management: aggregate, distribute, and maintain members' attribute data, syntax, and semantics
• Trust management:
  • federation and member operation practices and control
  • privacy and security policies

Things to Think About:

• Policy work is very slow, but critical - start early
  • Identifiers
  • Privacy
  • Content copyright
• Do not underestimate the difficulty of application integration with new or legacy infrastructure
• Authorization can be quite a challenge (e.g., how to identify subsets of people)
• Consider new support models
• Communication and coordination are key
• Keeping all stakeholders motivated and involved can be quite a challenge

Policy Issues:

• Which services reside where?
• How is vetting / credentialing performed?
• How do application owners determine required Level of Assurance (LOA) for their applications?
• How do Identity providers comply with applications' LOA requirements?
• Who supports the end users and applications?
• Who audits identity providers' practices and what standards are used?
• What is the role of Information Security Governance?

Federation Technology Standards:

• Security Assertion Markup Language (SAML):
  • Standard developed and ratified by OASIS, an international non-profit standards organization, and managed by the OASIS Security Services Technical Committee
  • Has broad vendor and industry acceptance
• Shibboleth:
  • Open source software package for web single sign-on across or within organizational boundaries
  • SAML-based software managed by Internet2. See other Internet2 middleware initiatives in higher education, including OpenSAML
  • Higher-education and increasing vendor acceptance
  • Provides extended privacy functionality
• WS-Federation: a specification developed by IBM, Microsoft, BEA, and others. OASIS now has a technical committee tasked with standardizing WS-Fed.
• Liberty Identity Federation Framework (ID-FF): now integrated into the SAML 2.0 standard.
• Open ID: a user-centric distributed web-SSO technology perceived as being lighter-weight and less focused on communities of trust than SAML

Benefits of Federation:

• Sharing of Resources
• Collaboration
• Increase security (fewer usernames and passwords to manage)
• Lower support costs (no application-based identity management)
• Improved user experience (fewer usernames and passwords to remember)

Challenges of Federation:

• Deploying new infrastructure is hard
  • The infrastructure must be there before gains can be realized, which makes justification a challenge.
• Policy development can take considerable time.
• Trust can be difficult to achieve.
  • Good policy and governance helps ("trust but verify")
• Making it ubiquitous across entities of varying size is a challenge.
  • Many times, it is the smaller organizations that can benefit most.

The EDUCAUSE Identity and Access Management page contains publications, presentations, podcasts, and blogs regarding the mechanisms to create a trusted authority for digital identities across multiple organizations and employ a single digital identity to access all resources to which a user is entitled.

The InCommon Assurance Program awards certifications to qualifying institutions of higher education and research organizations that support InCommon requirements for consistent management of digital credentials. Good security and identity practices help ensure that an individual using an electronic credential is the person you think it is. For Service Providers in an identity federation, having Identity Provider Operators support a standard practice set (or profile) can mitigate the risk of service compromise. For Identity Providers it is a way to provide single sign-on access to applications requiring an increased level of confidence in a credential. InCommon has published two sets of profiles: Bronze and Silver. These profiles align with the U. S. government's NIST levels of assurance level 1 and level 2, respectively. Bronze has a security level that slightly exceeds the confidence associated with a common Internet credential. Silver has a security level appropriate for financial transactions.

See CommIT: Simplifying Admissions Identity Management for Georgetown University's way to leverage federated single sign-on to match electronic records for college applicants and institutions using a single set of user credentials that can be used across various services.

See Social-to-SAML: Accepting Social Identities for InCommon Federated Services for an overview of how two institutions of higher education are using social identities (e.g., Google and Yahoo) to provide access to selected federated services for users who may have little or no continuing relationship with the institution. Presentation slides.

d. Cloud Computing and Software as a Service (SaaS)

Definition: Cloud [computing] describes the use of a collection of distributed services, applications, information and infrastructure comprised of pools of compute, network, information and storage resources. These components can be rapidly orchestrated, provisioned, implemented and decommissioned using an on-demand utility-like model of allocation and consumption.

(Cloud Security Alliance, "Security Guidelines for Critical Areas of Focus in Cloud Computing", April 2009)

Definition: Software as a Service (SaaS) is the capability provided to the consumer to use a provider's applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email).

(Cloud Security Alliance, "Security Guidelines for Critical Areas of Focus in Cloud Computing", April 2009)

For a comprehensive discussion of major identity and access management functions that are essential for successful and effective management of identities in the Cloud, see:

• Cloud Security Alliance (CSA) Cloud Security Alliance (CSA)- Domain 12 Guidance for Identity and Access Management V2.1 Institutions of higher education willing and able to leverage several cloud computing services need to extend the institution's identity and access services to the cloud as a prerequisite for use of on-demand computing services. The guideline discusses identity provisioning and deprovisioning, authentication and federation, authorization and user profile management, identity as a service when considering either software, platform, or infrastructure as a service.
• Identity and the Cloud - Preparing Your Campus. Managing security and privacy is an ongoing challenge, compounded by the expanding interest in software as a service (SaaS) and cloud computing. This EDUCAUSE 2010 Conference preconference seminar, and related materials, discusses how a growing number of campuses are turning to federated identity access to services, through the InCommon Federation, as a solution and the value the federation can provide to an institution infrastructure. Specifically, the concept and benefits of participating in InCommon, campus policy requirements, preparing institution identity management infrastructure, choosing and installing the appropriate standards-based software, and collaborating with other institutions of higher education and with resource providers.

Challenges:

• The decision to procure cloud computing services or SaaS may be driven mostly by individual departments instead of institutional IT strategy.
• Integrating separately developed applications into an integrated approach.
  • How to manage access?
  • How to manage provisioning?
  • How to integrate these applications into institutional web services?
• How to reduce the number of credentials

An Alternative Solution:

• Focus on four activities:
  • Develop an institutional Identity Management System
  • Create a standard set of attributes for each person (eduPerson)
  • Use a federation to enable external access
  • Require institutional developers and in RFPs that service providers support SAML and InCommon
• InCommon provides an easy to use framework for customers and service providers that will work across higher education.

Source: Jack Suess and Kevin Morooney "Identity Management and Trust Services: Foundations for Cloud Computing", EDUCAUSE Review Vol. 44 Sept/Oct 2009

See Supporting High-Value, High-Risk Cloud Services with Federated Identity Management to see how campuses are using federated identity management to meet the security standards needed to provide access to services containing sensitive data and what are the security and policy considerations involved in extending federated identity management for use in higher-valued cloud services.

The EDUCAUSE Cloud Computing Security page contains security, privacy, identity, and other compliance implications of moving data into the cloud as well numerous higher education and industry resources on the topic.

e. Mobile Computing and Teleworking

Teleworking (i.e., telecommuting), e-commerce, use of intranets, online education, and the increase use of portable computing devices (e.g., laptops, tablets, smartphones) are driving the need for access to information resources from any place at any time. Today's mobile work force or users are no longer just staff faculty, and students trying to check e-mail from home but part and full-time telecommuters, business partners, full-time students. and patients who rely on access to institutional networks to accomplish day-to-day business functions, attend classes, and follow-up on medical treatments. Information security controls specifically targeting mobile computing and remote access to information resources are becoming an increasingly critical component of any institution information security program ensuring the protection of the integrity of the institutional networks while allowing remote access to it.

Challenges of Mobile Computing:

• User Authentication
• Protection of Transmitted Data
• Protection of the Institutional Network

The enable remote access to institutional information resources, institutions of higher education are implementing Virtual Private Networks (VPN) technology to provide a secure connection to the institutional network. VPNs send data securely through a shared network. VPNs can be established between remote users and a network or between two or more networks thus using the Internet as the medium for transmitting information securely over and between networks via a process called tunneling.

The EDUCAUSE Mobile Internet Device Security Guidelines page contains helpful advice to develop mobile Internet device security policy, standards, guidelines and procedures. It is organized into easy to follow steps to define objectives,develop a plan, and answer some of the questions being asked by users and security professionals alike.

Top of page

Resources

Top of page

Standards

Top of page

Questions or comments? Contact us.

Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).