Identity effectively amounts to (at runtime) a principal that is defined by a set of claims.
Let's look at a couple of definitions of how identity is defined and used:
"Authentication binds a principal to a representation of identity internal to the computer. ..all decisions of access and resource allocation assume that the binding is correct," Matt Bishop
and
Kim Cameron's working definition and related discussion:
"A digital identity is a set of claims made by one digital subject about itself or another digital subject."
In a SOA world there are two compelling elements in Kim's working definition that augment Bishop's definition of how an identity is used. First, is that the identity (like other security assertions) must be made portable across domains and not tied to one computer. Secondly, the notion of claims is critical. A claim is subjective and can be evaluated based on criteria which evolves over time even in the span of a given transaction.
In the SOS architecture views we are concerned with identity from two perspectives. Internal to the Identity view, we have concerns such as how are we defining identity? By what mechanisms, use cases, and processes do we achieve identity, what processes are in place to verify trust in the claims that have been made, to what extent is the identity portable across domains, and finally how are applying protection, detection, and response mechanisms to ensure the desired state of confidentiality, integrity, and availability of identity?
External to the Identity view the relationships with other views the concerns center around what identity properties are consumable, verifiable or queryable by the other views, and to what level; what level of trust can or should the other views have on the identity (or principal), how can the other views use identity in their protection, detection, and response mechanisms? What effect do eternally visible changes in the other views have on the identity view?
The Message, Service, Deployment, and Transaction lifecycle viewpoint each use and supply specific elements and constrains to the Identity view. The next blog entries will explore these in more detail.
(Note: This work on Service Oriented Security views comes from a book that I am working on, if you are interested in reviewing sample chapters, drop me a note)
Comments