I recently participated in an interesting panel at the NYC Identity Access Management User Group. Moderating the panel was Shahryar Jahangir, a cloud and security transformation architect and participating panelists were Bernadette Gleason, Raymond (Ray) Ramos, and myself, Matthew Maichuk.
Prefaced with an initial question regarding “How to reign in the user access?” from an organization that was still new to IAM, the conversation really began to open up since there often exists multiple approaches and since problems often have multiple causes (in this case rubber stamping and poor deprovisioning).
The most engaging topics I found were: 1. the future of blockchain, and 2. the discussion around a recent solution where IDMWORKS facilitated an IAM overhaul that leveraged multi-tiered federation, datastore flattening, and provisioning/governance upstream and downstream across those structures.
The first discussion opened with “Do you think blockchain will happen?” The point was made to look at its current state and think about how Identity Management’s current state came to be. Most people are skeptical regarding block chain. It’s still developing, but it can be secure. Concerns are warranted – for example the 51% attack. Any consensus algorithm is susceptible to that until its adoption gets dispersed enough and this is a big hurdle preventing mass adoption. Technology that is commonplace now may have previously seemed extreme but here we are in a world where there are mobile phone games requiring multi-factor authentication. Nevermind that banks ask for a fingerprint, our entertainment is now asking you to verify who you are. 10 years ago that would have been entirely foreign. So while blockchain may not gain universal acceptance in the near future, with the speed at which these technologies move, it may just be commonplace after a few large organizations prove it’s usefulness. This reminds us not to disqualify a solution solely based on maturity.
We also discussed an interesting build I was involved in at IDMWORKS where virtualization, federation, provisioning, and authentication were designed in a way that, while still centralizing the information, the solution allowed the necessary complexity to account for several layers of employee types. This virtualized repository presented identity data across both an aggregated view, as well as an application consumption view, for both internal and external authentication where additional consideration was aligned for their various hardening requirements (MFA). The problem IDMWORKS was faced with was that disparate authentication resources resulted in multiple sets of credentials being created and had complicated the client’s MFA as it was resolving against multiple services. This, coupled with a redesign needed for user provisioning to eliminate the building of misconfigured accounts, and that deprovisioning was currently allowing for unaccounted for permissions to remain, had led to a need for a strategic review and realignment of the products and processes to enable the technology to deliver on the policies required by this particular client.
To accomplish this, after assessing the different needs of the organization and isolating the toolsets that could most effectively actualize them, the design delivered leveraged the following:
- a central virtualized directory that caches the legacy directory systems while serving as the target for the provisioning system;
- the ability for the virtualized view to filter and restrict data to provide what is specifically required;
- a new provisioning system that is robust enough to handle the logic required for the account types it will be encountering and able to acquire identity data from, and possibly prioritize data from, multiple authoritative sources;
- a series of identity providers that utilize the centralized virtual directory but can differentiate the access origin to ensure the proper credentialed authentication is used;
- and finally, an access provider built in a way to leverage the multiple federated elements for users to simplify there initiation of the process.
I described this as a concentric circle of identity, zeroing on a virtualized store sitting on top of a provisioning application leveraging the views presented by that new directory. Each circle lending additional capabilities, while understanding the security of the previous circle inherently. The alignment of the technologies to not only efficiently build an identity, but to present accurately filtered data at the right time across layers of carefully orchestrated measures in order to ensure we can trust the user has the access required, at day one, to perform their tasks with no additional risk added. All the while, being smart enough to understand the source of the access request as it pertains to device type, user attributes, and interface utilized (be it internal or external.) The project had similar notes to another I had seen where do to particular restrictions, the data needed to be kept within a nations border, so again the federated “layers” were employed, while being seamless for the users who were accessing the systems.
The great thing about these IAM User Groups is the openness of the participants sharing their challenges. What gets addressed isn’t necessarily hyper-focused niche solutions, but rather key ideas that serve as a core. While we did sometimes delve into involved topics, like how to address accounting for artificial identities and the feasibility of emerging technology, the conversation was always brought back to the higher level constructs. It was definitely a worthwhile investment in time.