I want to return to Nishant's concerns with the way I've presented IdMaaS:
What I was surprised to find missing from Kim’s and Craig’s discussion about IdMaaS were the governance controls one needs in identity management (and therefore IdMaaS) – like approval workflows, access request and access recertification. In other words, those crucial business tools in identity management that have led many analysts and vendors (including me) to repeat on stage many, many times that “Identity Management is about process, not technology”. And this is the part that makes identity management, and therefore IdMaaS, really hard, as I alluded to in my talk about ‘Access Provisioning in a Services World‘ at Catalyst a couple of years ago.
Let me begin by saying I agree completely with Nishant about the importance of governance. In fact, in my first blog about IdMaaS I highlighted two fundamental aspects of IdMaaS and digital identity being:
- confidential auditing; and
- assurance of compliance.
I also agree with him on the urgent requirement for “approval workflows, access request and access recertification.” I believe we need identity and access process control.
I'm therefore surprised about the confusion on whether or not I think governance is important, but I'm glad to get this cleared up right at the beginning.
Let me explain what I had in mind as a way to achieve some depth in this discussion. It seemed to me we need to decompose the overall service capabilities, rather than trying to discuss “everything simultaneously”. I started by trying to talk about the IdM models that have led us to the current point in time, in order to set the stage for the exploration of the new emerging model of Identity Management as a Service and its capabilities, as illustrated in this graphic:
Now my point here is not to argue that this graphic captures all the needed IdMaaS capabilities – it's very much a work in progress. It is simply that, when you look at the whole landscape, you see there are a number of areas that warrant real discussion in depth… My conclusion was that we will only succeed at this by looking at things one at a time.
The point can be made, and perhaps this is what Nishant was saying, that governance applies to everything. I accept that this is true, but governance still can be factored out for purposes of discussion. I think we'll achieve more clarity if that's what we do. For one thing, it means we can dive more deeply into governance itself.
Let me know if this decompositional approach seems wrong-headed and we should just have a free-for-all where we discuss everything as it relates to everything else. I agree that this can be interesting too.
That said, I want to take up some of the points Nishant makes when talking about governance in the Domain Identity Model.
In… ‘Identity management before the cloud (part one)‘, Kim says “In the domain paradigm identity management was thought to be the CRUD and little more.”. But that is not true. What made identity management so hard and expensive was the need to supplement the CRUD features with a governance layer that included policy and process to manage over the entirety of the identity management infrastructure. The responsibility for this was early on thrust upon the provisioning products like Thor Xellerate and Waveset, and later on spawned more specialized handling in IAG products like Sailpoint and Aveksa. Kim alludes to these when he says “A category of Identity Management integration products arose … often brittle point products and tools that could only be deployed at high cost by skilled specialists”. That’s accurate, but not because they were pointless or overhead or overkill. These products were difficult to deploy and needed customization because it wasn’t well understood how to introduce the controls needed in IAM in a manner that was practical and usable. And it was always assumed that every customer would demand unique business processes, so the approach was a toolkit approach rather than a solution approach.
Reading this, I hold even more strongly than before to the statement that the Domain Model was about CRUD and absolute control by The Domain. The fact that businesses required governance is historically true but doesn't change the way Domains were conceptualized, built and sold by everyone in the industry. So I agree with Nishant about the importance of governance but don't think this changes the essence of what domains actually were.
For a at least several decades computer governance was provided as an outcome of security analysts configuring domain based systems to implement a variety of well-known techniques (physical security, separation of duties, multiple approvers and the like) in order to satisfy business objectives and comply with normative standards prevalent in the industries and national or geographical jurisdictions.
I'm sure many of us witnessed the calisthenics of colleagues in banks and financial institutions, who, as security officers, figured out how to use mainframes and LANS in both their nascent and more evolved forms to be effective at this. I know I used to marvel at some of what they accomplished.
We are talking about a time when governance wasn't synonymous with government regulation. Governance was more or less orthogonal to the way products were built by the industry. Domain products could be used in ways that accorded with asset protection requirements if the right expertise was present to set the systems up to achieve these ends. And on a pessimistic note, has so much really changed in this regard since then?
Many of the provisioning concepts that appeared in products like Waveset and Xellerate appeared earlier in products like ZOOMIT VIA and Metamerge. But those, like Waveset, Xellerate and Aveksa were actually, in my view, “post-domain” products that attempted a holistic solution working across product boundaries.
Still, while being post-domain in some ways (e.g. meta), they continued to require extensive manual intervention by security experts to coax “compliant” behaviors out of them, and this intervention was embodied in detailed configurations and scripts dependent on the behaviors of underlying products. This meant they were often fragile: if the underlying products were upgraded, for example, they might no longer be compatible with the framework intended to manage them.
Nishant goes on to say,
And an IdMaaS architecture as alluded to by Kim and illustrated by Craig in this diagram just makes the solving of this problem more difficult and even more critical due to the zero trust environment. Since the identities have not been created and are not controlled by the organization that needs to make the access decisions, approval and review controls become even more important because they’re all the enterprise has. The ability to de-provision access based on events or manual intervention becomes a crucial component of access lifecycle management. These are the safety measures the organization needs to put in place for security and compliance.
I agree the ability to de-provision is key and in fact it is key to what we will be delivering. On the other hand, Nishant's conclusion that “the [IdMaaS] architecture.. must make the solving of this problem more difficult… due to the zero trust environment” is I think absolutely unfounded. As I will show when we go through the requirements for IdMaaS, Trust Frameworks are a necessity, and I know of few Trust Frameworks that are based on “zero trust”.
There is a bit too much flailing at paper tigers for me to take all of this apart in a single post. Let's take a deep breath and delve systematically both into requirements and the details of what is being proposed in WAzAD.
