Identity is changing. Our initial focus was on controlling and provisioning access to key systems for purposes of satisfying Sarbanes-Oxley audit points. Identity was the afterthought, access was king. Our name for a long time reflected that, the Access and Identity Management (AIM).
More and more we’ve been moving towards becoming the Identity Information brokers. It hasn’t been easy. Our customers have continued with their demands to get their applications added to our Computer Access web site (CAP). The business has demanded easier access for new hires which gave birth to the ‘On-boarding’ project. The folks in Compliance and I&T still have an audit point to satisfy with regards to privileges granted roles in each application, and likewise privileged access to systems and databases. Throughout all of this we’ve been in the process of upgrading out metadirectory server for nearly a year now.
But as we’ve been completing these projects, my attention has been drawn to what we’ll need in the next 12-24 months. Here’s some of my conclusions of where we are headed in the Identity Management:
1. Being the identity information brokers doesn't mean we have to build a monolithic database (and schema) to house every little last bit of information about our users. For one, we should only build out relevant information as it relates to identity or is consumed by another application or end user. Likewise, we’ll never agree on a naming convention, etc with all of our end users. Instead we should look to support all of the elements they need and provide a proper mapping to the same for application developers. We should focus on building out a structure that will allow for more generic, more meaningful, roles for our end users. The application development teams who consume this information will provide the mapping to their application roles. We should partner with those development teams to better report on the privileges our roles grant to end users across the application eco-system.
2. We need to embrace the concept of Identity as a Service (IdAAS). We should provide an identity service layer to allow applications and other services to readily get their identity information from us. What are the aspects of this Identity as a Service that are key?
- Highly available
- Highly reliable
- Highly standard
- Easily recognized
- Simple to use
- Usable (see Simple to use)
- Ubiquitous
- Critical to daily activity
- Taken for granted (see ubiquitous)
The best analogy I can give for this Identity Service Layer is one of the old phone system (prior to cells). Applications should be able to lookup key elements of identity for a user of their system with the ease of using a Yellow Pages or a phone book. The elements like name, address, and phone number should be VERY easy to get from it. Likewise, simply pick up the phone and you’ve got a very, very, stable, always on, service layer waiting for your input. Simply dial the number of the end users and your application could be talking to them in moments. This also speaks to the need for an elegant API.
3. The API we develop for accessing this identity service layer should be very simple. We should not force our application development partners to learn new standards, or complicated SOA schemes. My preference is for a simple REST-ful interface. Federation is where we will need standardize our communications with trusted partners.
4. Federation is a key to our success with vendor and student/faculty integrations. As as move to a service oriented world, integrations of our end users with various vendor applications and even access to our student and faculty portal will be critical. We’ll have to provision and de-provision users to and from their systems. Our initial approach is going to help to ease multiple logins to vendor systems internally. Our focus should be to allow staff to access vendor sites from home or other remote sites without having to remember their passwords. This will take some time to complete. The first step should be federating our identity repository information with existing vendors. From there we can begin to look at the student and faculty portals. I believe we should have an awareness of student and faculty identities in our internal identity repository. I don’t believe this requires that we provision and de-provision students and faculty (although I would certainly prefer we leverage a common identity framework) as that is the particular domain of the people vested with maintaining those applications.
5. Replication and copying data demands will grow to the point where it may become untenable. Metadirectory tools like MIIS and ILM are based on a Web 1.0 paradigm where it is relatively simple to determine who owned the data. There was HR data, Galaxy data, CT & OSIRIS data and so on. Today’s applications are sharing data, components, and identity information. Who owns the data is becoming less and less important and clear. As we grow our IdAAS and IDM Service Layer, we will be forced away from ILM as a hub for identity information and driven towards policy and user centric information sharing. This change is still roughly two years away but we need to consider the buy vs. build solutions now that will allow us to remain competitive and relevant.
6. Identity’s importance to the enterprise will continue to grow. Enterprise 2.0 and Web 2.0 will change our business models and our strategies will need to adapt. Identity is the FOUNDATION for all of this. Identity will grow to not only encompass systems and database access, but physical and user access to laptops and desktops. The Identity team will work more closely with the HR Team as it pertains to the identity lifecycle. But as our scope grows we will HAVE to staff up to meet the demand, simple decisions to purchase software in an attempt to minimize man hours spent developing custom applications will not suffice to meet the demand. The key will continue to be employing highly intelligent, highly effective people to extend, implement, and support our identity initiatives.
7. The computer access web site will continue to become less and less important. We should focus on breaking it up into viable, independent pieces to be consumed in other applications or modalities. The computer access web site will need to live on for the next 18-24 months or until we acquire an identity management suite. At the point where we implement any new identity management suite, we may be able to employ the gadgets or pieces of the old computer access web site that we develop. More focus should be given to building our Identity Service Layer (with consideration for an Identity BUS to be implemented as a part of a larger enterprise service bus) and the tools necessary to support it.
This is my vision for the next two years. I would love to hear from all of you and your thoughts on the future of Identity Management in the Enterprise for the next two years.
