Don't let the conversation for the design of an Identity Management deployment start with “We need to have an RBAC!” If anything from my previous post, the conversation starts with looking for the data upon which to base the decisions for RBAC You can have all the locks you want, but if you issue keys based upon proper background checks, it is just another open door. The real issue is how to deliver the “here!”, “now!” and “right” of the information.
In my experience, the application designer and subsequent developer wants to know that the information asserted by the identity management process will be valid for each state in the access management process. The object (their code) will have a defined input and a defined output. To illustrate how the key points of the Parkerian Hexad is useful in evaluating how best to design an identity management process, let's take, as an example, the first step in an access management process (the usual consumer of the identity management information.
The authentication (AU) set of tasks is expected to, unequivocally, assert that the person (or computer agent) is who they say they are. A good security framework for access will spare the developer the details of that process. The best scenario is that this process is handled transparent to the initial entry in a web service, such as a protected web page. In other cases where it is part of a sequence of tasks, the process input is a “call” and the defined output (return) would be a Boolean “true” or “false.”
As with any object, the actual logic is opaque to consumer, but always with the underlying assumption that the object will perform its task with an accuracy equal or better than the defined Quality of Service (QoS) defined in the business requirements. To meet that, it needed to leverage the following methodology:
1. The interface between the client agent (asserting its identity) and the server (verifying the identity) must be handled with an understanding of complete confidentiality. Each side of the “conversation” between the two be handled properly. The form presented and used (in the case of a web site) would protect the user from tampering of the code requesting the credentials as well as protecting the confidentiality of input of the data. Entering a password, even by hiding the characters behind a set of asterisks is low on my esteem for protecting confidentiality. On the server side, I would look at how the information used to verify the credential information was provisioned and how it is being used in the verification process. There is a big difference in security between a server hashing a an inputted password and doing a “compare” with that of, for instance, an LDAP bind. Stealing the code of from the server reveals both the key and the algorithm!
2. While the process between the client agent and the server must always address the issue of possession or control (for example, using SSL to prevent Man in the Middle attacks), the issue for Identity Management is the extension of that to include how valid was the process that handled the information as it was placed into the identity store initially for the authentication process to continue. Failing to consider the complete “chain of custody” may lead to a incorrect decision based upon false information.
Underlying the exchange of information is the assumption that the information itself was not compromised and its integrity was preserved. The process of authentication within access management may address part of the problem, but you need to apply “chain of custody” to the additional process of provisioning (as in, “exactly how are you making sure that the data copied from the data source of record to the identity store is correct”).
4. Similar to integrity is the requirement for authenticity. In the process of authentication, where the very question is about the authenticity of the user (through a client agent), one could lose sight of the fact that we are also asking about the authenticity of the information upon which the decision is being made. Again, we need to look at the “chain of custody” in considering how well to trust the information, such as a function of the number of “hops” it took and from whence it came. One should be very wary of moving HR information, originally from PeopleSoft, through an Active Directory to the Identity Store. The preferred method is to move information directly from PeopleSoft into the Identity Store, not because of the security of Active Directory, but the possibility of modification of data by those granted access.
Next post … further into the methodology as look at the last two of the Parkerian Hexad as requirements for building a better identity management system as part of a security framework. We will then translate these requirements into design principles for an identity management system and security objectives as performance criteria.