Nov 10, 2008 - but integrate with other systems to provide a complete solution, such as a corporate portal and access management directories. Business ...
© ARTVILLE
Kim Tracy
Identity management systems
M
ost organizations have difficulty keeping track of and controlling all the user identifiers and passwords across their systems. In particular, with people leaving the organization and constantly changing roles, it is more difficult to make sure every user has appropriate access to the systems. In our case at a university, we constantly have new students arriving and former students leaving. New students need access to our systems to register for classes and use e-mail, library resources, and the computing labs. Former students should no longer have access to systems we don’t have permission to provide (such as some library resources) or don’t have the capacity to continue to provide. At companies, similar problems exist with new and former employees, as well as the need to meet requirements from laws such as Sarbanes-Oxley regarding who is permitted access.
Digital Object Identifier 10.1109/MPOT.2008.929295
34
Identity management (IdM) systems are designed to help manage user identifiers across multiple systems as well as providing a way to manage user access over their lifecycle of roles in the organization. They are tightly integrated with other systems such as those that provide a single sign-on mechanism and the checking of their credentials. As such, these IdM systems have become extremely common in information technology infrastructure.
A defined role IdM is part and parcel of a larger system of identity and access management systems. IdM systems work hand-in-hand with access management to allow people to use their various login accounts. A definition of identity and access management, according to Mark Berman and Joel Cooper, is as follows: An Identity and Access Management infrastructure is a collection of technology, business process, and underlying policy that enables networked systems to determine
0278-6648/08/$25.00 © 2008 IEEE Authorized licensed use limited to: Kim Tracy. Downloaded on November 10, 2008 at 09:44 from IEEE Xplore. Restrictions apply.
IEEE POTENTIALS
The overall architecture of how IdM fits into a system framework is detailed in Fig. 1. Not all systems are designed this way, but this gives a general picture of how they tend to be devised. IdM starts by having some authoritative source of information that tells what users should exist (and not) and what they should have access to (and not). In many cases, that authoritative system would be an enterprise resource planner (ERP) such as SAP, Baan, or Great Plains, among others. Periodically, those users would be sent to the IdM server so that it can: •• provision (create and assign resources to) those users •• deprovision (remove them from the systems) or •• disable them (temporarily not permit them to use certain resources).
The IdM server would then create those users and, depending on the roles assigned, allocate access and accounts on the various system resources. In Fig. 1, those include an LDAP (lightweight directory access protocol) server, a Novell eDirectory server, and Microsoft Active Directory server. This resource tier contains systems that the IdM system can provision directly as well as generally controls other system access. For example, the LDAP and Active Directory servers are often used as primary ways for other systems to check login credentials. Users then can use their accounts to log in to other systems or into directly provisioned resources. For example, if one were logging into the Microsoft Exchange e-mail system, their credentials would be checked via the Active Directory system. Similarly, if they
Authoritative User Source(s)
Novell Directory
Active Directory Server
Lo gin
Other Messaging Server
Login
LDAP Server
IdM Server
Login
•• Microsoft’s Identity Integration Server •• SUN’s Java System Identity Manager •• Computer Associates’ Identity Manager •• Novell’s Identity Manager •• Oracle Identity Management •• HP’s OpenView Identity Management •• NSF’s Middleware Initiative (See: www.nsf-middleware.org). The Berman and Cooper definition has several key components: •• Collection of technology : Usually, these are not individual systems but integrate with other systems to provide a complete solution, such as a corporate portal and access management directories. •• Business process and underlying policy: Besides the technology we focus on in this article, just as important are the processes and policies used by the organization. For example, a consistent and reliable process is needed for how new users get added to the system as well as assigning what system resources to which they have access. The policy refers to the policies the organization has for who should have access, to what they should have access, and for how long should they have access. •• Networked systems: We are focusing on networked systems and providing a method for accessing them over the network. Most often a goal is to provide integrated access so that the same password and account name work for every networked system as well as providing a method for signing in just once and then passing that sign-on information to every networked system (a.k.a. single sign-on). •• Access and authorization : Access management checks a user’s credentials to make sure they are who they claim to be. That could be via a password or other credentials. Authorization refers to what the user is allowed to do. While someone may have access to a database, we also need to know what they authorized to do.
Overall architecture
A ut ho ri za tio n R eq ue st
who has access to them, what resources the person is authorized to access, while protecting individual privacy and access to confidential information. Some examples of IdM systems include:
Login
Other Systems (Portals,ERPs, etc.)
User
Fig. 1 An overview of identity and access management.
NOVEMBER/DECEMBER 2008 Authorized licensed use limited to: Kim Tracy. Downloaded on November 10, 2008 at 09:44 from IEEE Xplore. Restrictions apply.
35
were logging into another e-mail system, their credentials may be checked against the LDAP or Novell eDirectory server. Alternate approaches largely consist of how the directories are organized. Some organizations can standardize on a single directory making the environment simpler and easier to manage. However, many cannot due to legacy environments and the ease of integration with a particular directory for some systems (which can vary). Another approach is to use a metadirectory to help manage the directories. Since we had not already implemented a metadirectory, the IdM gives many of the synchronization benefits making a metadirectory less appealing.
Four challenges While the overall architecture is relatively simple, there are other factors that make the installation and management more challenging. Four of those factors are the definition of roles, the propagation of the user accounts, initializing the system, and integrating with single sign-on systems.
Defining roles Roles are used to help aggregate authorizations into meaningful groups so that individual people can be assigned roles and get a set of authorizations to specific systems and resources. In a university’s case, those are minimally roles like student, faculty, and employee. These allow the system to automatically create accounts and system access to a set of resources. So, we can create a set of resources for the student role such as their e-mail account, learning management system account, and on-line registration. The issue becomes how to define those roles such that they are consistent with the underlying system roles. For example, our ERP system maintains a set of roles for the ERP, as does our portal system. So, while we may assign a student role, the ERP may have graduate student, accounting major, and more, as roles in the ERP. Our approach so far has been to keep the number of roles at the IdM level small so that they fit clear groups. There is also the issue of multiple roles and definition of a primary role. For example, we have some individuals who are a student, a member of the faculty, and an employee—all at the same time. In order to decide to what
they should have access, we assign a primary role. For example, if they are primarily an employee, then they should also get student resources (like the learning management system). If they have only student and employee roles, then the distinction is clearer. In that case, if they are a student who has an employee role (a student worker) then they should be primarily a student and use mostly student resources. If they are primarily an employee, then they should use the employee resources. For us, that distinction is critical as student and employee e-mail are on different systems. Changing roles also proves to be a challenge as it may mean the user has completely different resource allocations. For example, if the user changes from being a student to a full-time employee, then they should be on the employee e-mail system. While creating
Changing roles also proves to be a challenge as it may mean the user has completely different resource allocations.
Initializing the system When a new user is added to the system, they need to initialize their account with a secure password. This is critical as the new credentials will provide integrated access to all of the organization’s systems to which they have access. A method has to be devised so that a new user can identify themselves to the system securely and then to create a hard-to-break password. The method often used to validate their identity is to request them to answer questions using personal data that only they should know. This data often comes from the ERP system and could include other unique identifiers and keywords that they should know. Once they have done this they need to establish a strong password. A strong password is one that should be hard to break and generally is at least eight digits long and includes upper and lower case characters, special characters, and numbers. Other requirements can also be added to strengthen the password such as not having any words in the dictionary over three characters. The more constraints that are on the password the harder it is for users to come up with a password that meets the constraints, however, it will be harder to break.
Integration with single sign-on the new account via the IdM is relatively straightforward, we need to migrate their old, student e-mail to the employee e-mail system.
Propagation of accounts Many systems will need to have some local account information so that people can log into it. Our portal system requires local accounts, but then verifies the password entered against the LDAP directory, as does our learning management system (Blackboard). However, we need some automated way to get those accounts loaded into those systems as the IdM creates, disables, and deprovisions them or they quickly get out of sync. Ideally, the IdM would directly populate and update those accounts based on role into those systems. However, that may not be the case and would then require some sort of a file be sent periodically between the IdM and the systems that require local information.
One of those systems that uses the resource tier (such as the LDAP, Novell, or Active Directory) is a single sign-on mechanism. Ideally, once the resource tier is set up, one can also have methods that allow users to log in once (such as to a browser) and then access all the system they have access to without having to log in again during that session. Using an IdM and access management solution makes it easier to deploy such a solution as the passwords and accounts should all be synchronized. For us, we are currently using the single sign-on capabilities of our intranet portal system, but may also move to integrate the sign-on to the workstation so that they only have to sign on once.
Implementation details For our implementation of an IdM, we had several directories providing authentication information, none of which were synchronized. We have
36
IEEE POTENTIALS Authorized licensed use limited to: Kim Tracy. Downloaded on November 10, 2008 at 09:44 from IEEE Xplore. Restrictions apply.
The big picture This article describes the basic principles of access and IdM and an implementation using state-of-the-art tools and systems. Access and IdM has become more complex, but at the same time even more necessary to provide a secure environment. The
CARS SIS (Will be Banner ERP)
Sun IdM Server
Authorization Request
Accou
Login for /printers sh File ares
Staff Login
Login Luminis, Blackboard, Library Systems. Remote Access, Student, Printing, Access Student E-Mail, Banner (Future)
Active Directory Server
nt Setu p
Novell Directory
LDAP Server
Authorization Request
Novell for file system shares and printer access, Active Directory for access to Exchange, and LDAP for control of a number of resources including student e-mail, library access, and remote access. We were in the process of implementing our intranet portal (Luminis) and this made it a good time to also roll out our IdM. In preparation for the integration, we made plans to link more resources such as our learning management system (Blackboard) and the Luminis portal to the LDAP directory. We are in the middle of implementing a new ERP system (Sungard Higher Education’s Banner system) and are currently using our old ERP (Jenzabar CARS) to act as the authoritative source of user information. The design had to accommodate moving to use the new ERP system when that is ready. We ended up choosing the Sun IdM system to integrate with our existing resources. (This is not a recommendation for the Sun solution, but it was the best choice for us at this time. Other solutions are also viable such as those noted at the beginning of this article.) The primary reasons for choosing the Sun solution were because we already had many of the components from Sun, our critical systems are running on Sun servers, and the Sun solution is a fairly mature and complete solution. Working with a consulting company (SimpleSoft), we created the resource adapters necessary to connect to Novell, Active Directory, and LDAP and are currently working on automated interfaces to load Blackboard and Luminis directly. Fig. 2, presents the overall architecture of the system. In Fig. 2, we have chosen to use our LDAP server for most of our authorization requests. We also have users directly logging into the IdM server for their account setup. We expect to further secure our environment using the Sun Access Manager product (basically, a reverse proxy to allow secure access via the Internet to internal resources) and integration of single sign-on access via our Luminis portal.
User
Exchange Server
Fig. 2 Implementation of IdM at Northeastern Illinois University.
primary intent is to build a role- and policy-based mechanism for managing system access so that it is manageable and enforceable. Without such as a structure it is difficult to keep track of who has access and to what they have access. The approach described here takes a multi-layer approach with feeds coming in to identify new individuals and roles to the IdM server. The IdM server applies policies and rules to provision, disable, and deprovision accounts in directories and systems. The systems then use the directories to validate credentials presented by users. While this system implementation was challenging, it is vital to any organization with a lot of user churn. At a university, we constantly have new students and graduating students making
the churn of user accounts very high. This gives us a basis for offering and being able to manage role-based services with a limited staff.
Read more about it • M. Berman and J. Cooper, “Identity management for the rest of us: How to grow a new infrastructure,” presented at the Educause Mid-Atlantic Regional Conference, Baltimore, MD, 2006.
About the author Kim Tracy is executive director of university computing services at Northeastern Illinois University and is responsible for all IT systems and resources. He is a member of the IEEE Potentials editorial board and a Senior Member of the IEEE.
NOVEMBER/DECEMBER 2008 Authorized licensed use limited to: Kim Tracy. Downloaded on November 10, 2008 at 09:44 from IEEE Xplore. Restrictions apply.
37
