Corralling Identity Management

• By Dian Schaffhauser
• 08/22/08

The University of Texas Health Science Center at Houston recently reconstituted its IT organization to include a new team focused solely on identity management. In the course of its work the team may end up becoming a model for how identity management can help deliver business value beyond standard IT duties, such as adding new users to the network.

William Schneider, identity management team lead, said the purpose of his group is to manage the identity and access infrastructure, which consists of multiple ID management systems, many of the enterprise directories, and the Center's public key infrastructure.

Individuals within the HSC community, which includes about 3,775 students and a staff and faculty of nearly 4,440 in eight different schools, may go through multiple roles during their time with the Center. A student, for example, may achieve an MD, then transition into a residency and perhaps eventually become a member of the faculty. Often the same person may be an employee, faculty member, and student simultaneously.

"The identity management system ties all that together," said Schneider. "It makes it such that you could have the same e-mail, password, and inbox throughout that entire lifecycle."

The Center has five "systems of record": the human resources system, which resides in PeopleSoft; the student information system, maintained in a DB2 database running a mainframe emulator on the front end; a resident system, called Graduate Medical Education Information System (GMEIS), basically, an HR system that does evaluations, duty hours, and rotations and scheduling; an HR system for the Faculty Practice Plan for the Center's physicians; and a guest database for anybody not in any of the other four categories.

A First Attempt at Identity Management
In the past, that wealth of data from multiple sources posed several challenges. There was no simple way to know which data store to use when a person was maintained in more than one. Likewise, it was hard to reconcile those five systems in order to do a match to determine if an individual in one was the same as the individual in another.

University of Texas guidelines mandate that the Center assign a persistently unique identifier to a single individual forever, explained Schneider. Yet those same guidelines say that a social security number can't be used--unless it's collected for another purpose, such as employment. So those linkages needed to be created in some other way.

About eight years ago, the Center's academic computing group developed an application called Integrated Directory Service (InDiS). Each day, InDiS did a daily feed from each of the five data stores, performed a reconciliation, and fed it into an Oracle database, referred to as the "Person Registry," which populated a single LDAP-based Sun enterprise directory.  This was and continues to be based on Internet2's Enterprise Directory design guidelines.

Few other applications at the Center used the directory, and none of the desktops actually logged into it for authentication.

Choosing Novell Identity Manager
Then four or five years ago, Schneider said, there was a move afoot to consolidate mail systems across the Center from about a dozen to a single one: Microsoft Exchange. That also meant extending the Active Directory deployment to a much larger scale. So the IT team needed to figure out a way to take the data from that Sun directory and recreate it in Active Directory, plus integrate an e-directory that had been in use at the University of Texas for about 15 years.

"We looked at that and said, 'OK, we can take the existing application and extend it and write custom code. Or we can look at commercial applications," Schneider recalled. "When it came down to it, maintaining our own code base wasn't where we wanted to go, if we could avoid it. We're a health science center, not a software development house. We decided pretty quickly to look at a commercial solution if it would meet the needs."

Contenders included Microsoft Identity Integration Server (now called Identity Lifecycle Manager), Sun Identity Manager, and Novell Identity Manager (formerly known as DirXML). Microsoft was knocked out because, Schneider said, it worked more in batch mode than real time and "required everything to be reconciled into a SQL database, which may or may not have been advantageous."

The Sun product required that "you had to write Java classes to do anything, and it was based on a virtual directory structure. You wouldn't actually synchronize the data," he said. "We wanted these directories to stand on their own if something got knocked off in between."

The Novell solution met the criteria for being an event-based, real-time identity management system. With about 20 different drivers, the integration capabilities were extensive, and configuration was based more on setting up business rules than on writing code.

Schneider and his colleagues focused on figuring out how well the Novell product could carry that Person Registry into Exchange. Prior to the initial deployment of Novell's ID Manager, the IT organization had been creating accounts manually in both Active Directory and the legacy e-directory. Administrators had to terminate accounts manually and only had valid data for employees. InDiS would populate a new e-directory, which then synchronized users to Active Directory and other directories. That movement of data (with certain attributes) into Active Directory causes Exchange to provision an account as well. They ran it like this for about three years. The drawback was that it was run in batch mode. The data on new users arrived once a day, and any changes took 24 hours to complete. But, said Schneider, "This was infinitely better than manual provisioning and deprovisioning."

By replacing InDiS with the ID Manager software, Schneider and his colleagues hoped to move closer to an end-to-end, real-time, event-based system, what he calls the "holy grail."

"This means that on your first day of employment or classes you are provisioned with everything you need and you don't have to go hunting for access or spawn more processes that are out of band," he explained.

Schneider and a co-worker spent six months setting up connectors between each of those systems--PeopleSoft, DB2, and the others--to connect directly via ID Manager drivers to Novell's eDirectory, which was to become the Person Registry. Another ID Manager driver moves the data into the enterprise directory service, called Identity Vault and composed of a number of different directories and applications, including Active Directory, Tivoli, and others.

"Right now, if I'm a student and I go to register in the registrar's office, within 30 seconds of the registrar saying, 'Yes, you're registered for classes,' I've got an e-mail account, VPN access, access into Blackboard--most of what I need to start the first day of class," said Schneider.

Achieving Agility
The Novell software has enabled the IT organization to become much more agile. As an example, the HR organization, which uses PeopleSoft, had stand-alone user names and passwords for that application. They wanted to move to single sign-on authentication. But a requirement of the request was that the IT department also go through annual disaster recovery testing at a third-party site, which would require hauling the ID management system to the test site in another state and then bringing the system back up within six hours. That surpassed the level of business continuity required for the whole ID Manager operation. So the IT group came back with an alternative suggestion: to set up a stand-alone directory directly on a PeopleSoft server, which gets backed up with the rest of the PeopleSoft application. During a disaster recovery scenario, the directory used by PeopleSoft for authentication is restored alongside everything else. "They don't have to involve five other people and reconstitute a bunch of directories," said Schneider.

Delivering that took only seven days, he said, from original request, through scoping, through a test run, to production and deployment.

Although Schneider said he believes other identity management products currently on the market would probably offer the same capabilities, "Could I do it that quickly with other products? Probably not."

Yet, ultimately, the current benefit of using Novell ID Manager is that nobody has to do daily administrative tasks, such as set up accounts, turn them off, or do password synchronization, he explained. The true value will come when the system can address real business needs.

As a health science center that gets a great deal of funding from federal sources, there's a big focus on compliance regulations including HIPAA and CFR 21 Part 11. "Right now, there's not a clear definition of it," he said. "If an auditor came in and said, 'What does this person have access to?' well, I know a lot of things they have access to, but I couldn't say 100 percent without a shadow of a doubt. I want to get to a point where I can say, 'This person has access to these 12 applications. They gained access on this date. They had access revoked on this date. Here they attested annually that they needed it.'"

Getting to that level of record-keeping, Schneider explained, requires a different approach to account provisioning. Currently, the overall system of user account management relies on data coming from multiple sources, sources that don't necessarily maintain the details about any given user's access. "The HR system was not designed to create e-mail accounts," Schneider said. "The registrar's job isn't to give students access to Blackboard. Their job is to register students and to hire and manage and retain employees."

That disconnect between the data maintained by different organizations at the Center and the data needed to manage users reared up a few years ago. A core Web server relied on HR data that used a particular department name for one of the IT organizations at the Center. That department name changed, so it changed in the HR system too, which then populated down through the directories. All of a sudden, none of the administrators could access the Web server. "HR had no idea that the department name affected people's access to a Web server. Nor should they have to have that knowledge," said Schneider.

The Next Phase in Managing the Digital Identities of Users
So the philosophy under which the identity management team will work is that although the data they have access to can help make decisions, it can't be relied upon 100 percent of the time. "There will always be exceptions, it'll always be somewhat inaccurate, and there will always be some degree of latency," he said.

That means the traditional approach of handing out access to services on the network based on the presence of a user within a given system of record, or having a given job title, role within the organization, or department must be eliminated. "Right now when you get provisioned, you get a lot of things by virtue of having an account," Schneider explained. "In our Windows Server team, there are three people who do Exchange management. Does everybody in that group need access to do Exchange management? No, but they all have the same title and work in the same department. Every bit and piece that we have says they're identical. But they don't need identical access."

In the new approach, access will be minimal, and users will need to have some way to identify additional network and application access they require.

"For instance," said Schneider, "if I'm an employee on day one, one [service] may be VPN access. Another might be an e-mail account. Because I'm an employee, I get both of those automatically. If I'm a student, I get an e-mail address. I can have VPN access if I go in and request it, and it'll be provisioned automatically. I need to go in and turn it on myself. If I'm a guest, I don't get an e-mail address. I don't get VPN access. I can request them. But that [request] will initiate a workflow to be approved by the person who approved my guest account and maybe some secondary person."

Beyond that the permissions issuance can get even more granular. The researcher with a large grant from the Department of Defense, for example, needs to know that the only people with access to a given database or application are the ones he or she has approved for access.

Getting Buyer-side Buy-in
That level of service delivery, Schneider said, will result in "business-side buy-in" from the administrators, researchers, and department heads at HSC for the changes his team will be introducing. "Most of the time, the way you get that buy-in, we've found, is to show the value they're going to get back. When a registrar can look at that student and say, 'When I finish registering you, you'll be able to log in at that kiosk and send an e-mail to your professor,' there's a value there. That's why they'll want to tie into this infrastructure."

But he's quick to add that he doesn't expect to modify the processes those individual groups follow in performing their core activities. "We've tried very hard to integrate to existing processes and to be secondary to them. From the technical perspective, the identity management software really allows us to do that because the integration occurs at a level that's transparent to these systems."

For now, the new identity management team is picking off high level items--VPN and e-mail addresses--and getting that infrastructure in place to do automated workflow and provisioning. From there, they expect to start seeing more attention paid on the part of the business users to how more specialized services are provisioned from the time they're envisioned. It'll become "part of your RFP process for your new application," he said. "You're going to have to answer, how do you address this aspect of the IT side of whatever you're buying?'

"Once you start going down this road, it gains a critical mass," said Schneider. "You don't have to go out and seek out these applications to add in because the customers are seeking you out."