Taming the "Identity Beast"
Look up the definition of Rube Goldberg in a dictionary, and you’ll find a system diagram of the UC San Diego identity and access management ecosystem. Like many large research-intensive universities, our “identity system” is a collection of heroic programming efforts, miscellaneous database tables, homegrown applications, and what may be the most complex Shibboleth configuration in the country, supporting three separate password stores (AD, Kerberos, and RACF).
If you’re not familiar with a major university, it’s important to note that our community demographics and service portfolio makes us look more like a municipality than a business. A city with a major medical center, ~10,000 new students every year (and another 10,000 who become alumni who we need to remain in contact with), traditional business functions (payroll, procurement, PCI), teaching (both online and in-person), tens of thousands of researchers working across the globe, not to mention our own fleet of ships, some of which only come to US ports once a year. For us, the very notion of ‘an affiliate’ is challenging: an individual can be a parent, a student, a faculty member, an administrator, a patient, and an alumnus all at the same time, each with a different set of access rights and privileges.
When we decided to embark on a wholesale replacement of our environment, we decided on a few crisp high-level goals (in addition to a long list of detailed requirements) to help set a posture towards all future identity work.
1. Make the person the center of the identity
2. Make joining our community as an affiliate easy and with a consistent process for all use cases and support for ad hoc and unpredictable changes to their affiliation
3. Provide seamless support for people with multiple affiliations with the institution
4. Link all person information to the identity persona
5. Empower multi-institutional research and collaboration
From a technology perspective, we decided to align our identity efforts with our general architectural direction: real-time event streaming as our integration strategy and SaaS as an application strategy. We were also painfully aware that we had overloaded some components of our legacy environment. The resulting complexity created formidable technical constraints. For example, our legacy ‘mail database’ managed email provisioning, affiliate records, AD provisioning, username and email address generation, and much of our email alias infrastructure. This accretion of function (and technical debt) grew from nearly twenty years of stop-gap code.
In order to avoid recreating this problem, we chose to deconstruct the identity ecosystem into a modest number of functional areas, each handled by a dedicated, best of breed solution, selected to provide us with maximum flexibility and to avoid locking us into a monolithic solution that would limit our ability to change as our identity related needs evolve.
Monolithic identity solutions do some things well but are not mature across the entire suite of the identity function
As we reviewed the market for true SaaS identity solutions, we found it to be fledgling and immature. Many of the SaaS offerings are point solutions that handle part of the identity ecosystem (e.g., single-sign-on) but not the entire digital lifecycle. Others are merely toolkits—little more than libraries of APIs within a framework. Still, others were simply traditional on-prem solutions hosted by the vendor. We finally selected Sailpoint’s IdentityNow SaaS product for its rich feature set as well as being a true SaaS package.
We ended up with 5 major areas: identity aggregation, deduplication, and ID generation (CoManage, opensource), Group management (Grouper, opensource), governance, certification, and (most) provisioning (Sailpoint’sIdentityNow), social identity (Cirrus identity) and of course SSO and Federation (Shibboleth, opensource, and some Microsoft ADFS).
This division of labor accomplishes several things. Monolithic identity solutions do some things well but are not mature across the entire suite of the identity function. Each element of our identity ecosystem is a best of breed product. Our open source solutions and one of our commercial products (Cirrus identity) were developed by or for higher education and thus reflected the unique features of the higher education environment. This includes the ability to rapidly modify core functionality, support for a heterogenous directory environment, and highly delegated management functions. Finally, by taking this modular approach, we gain the flexibility to change any area without having to replace the entire ecosystem.
We’ve learned a lot of lessons as we begin deploying our new environment:
1. The SaaS identity market is getting better but you should expect to cobble together a solution. This has advantages, and in a complex environment, those advantages will outweigh the apparent increase in complexity. For smaller institutions, the market looks a bit more complete.
2. The market for cloud services is still struggling to find reasonable business models. A SaaS-based product that is doing real-time analysis of user attributes and making provisioning decisions based on those attributes is costing your vendor real dollars in compute cycles, and someone’s going to pay for that (hint, it’s you). A hybrid solution may be cost-effective. We intend to leverage federation and social identities as aggressively as possible, using Sailpoint as a kind of ‘recency cache’ of active UC San Diego identities requiring accounts.
3. Pay close attention to your system and data integration strategy. Manage your own APIs for downstream applications to access data to avoid creating arbitrary dependencies on vended products (we found over 900 downstream applications needing remediation analysis for merely our soon to be replaced finance system).
4. Recognise that the need to provide every identity is legacy thinking. Higher Ed was forced to embrace federated access long ago due to the collaborative nature of education and research. We’re now beginning the shift to federating with the major providers of social identities for more core services; frankly, if Google can manage 3 billion user identities, why must we manage any?
Identity management has the reputation of being complex and difficult. In our environment, we have historically permitted that belief to limit us. Identity management is a core business function fundamentally about curating the relationship we have with our community from the cradle to the grave. In recognizing this, we have finally begun to move aggressively to a new environment, leveraging contemporary technical solutions, a rigorous planning process, and architectural rigor. The Identity beast can be tamed.
Check this out: