Kim Cameron's seminal "Laws of Identity" defines ways that identity systems succeed and fail in the wild. Web Services systems provide an interoperability layer that bridges technologies, geographic, and organizational boundaries. They also carry identity data. Web Services standards open up interesting new ways of dealing with age old problems in distributed programming. One area that we explore in my SOA, Web Services, and XML security class is how the Laws of Identity inform the security architecture for Web Services. Identity is usually thought of in terms of user facing components, plus directories, and other controls like encryption, but there are just as many implications in the machine to machine type world that Web Services works with. Here is an excerpt:
Law 1: User Consent and Control
Description: Technical identity systems must only reveal information identifying a user with the user’s consent.
Implication: Web Services implement interoperable Message Exchange Patterns across multiple systems, the security architecture must deal with how identity data protected as it is ported across organizational and technical domains.
Law 2: Minimal Disclosure for a Constrained Use
Description: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
Implication: What options are available to consume identity information in a distributed system? What is the minimal dataset or set of references required to do this? What options require on line or off line replication?
Law 3: Justifiable Parties
Description: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship
Implication: Web Services’ base use case is interoperability -presumes the presence of one or more intermediary systems (likely many more), how is the identity information made available to only those that have a justified purpose? WS-Security headers, SAML, and XACML all may be used to make sure the postal worker does not have direct access to the envelope's contents
Law 4: Directed Identity
Description: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Implication: Web Services are frequently used in peer to peer and ESB scenarios where messages may traverse many directions in the system, since these are hard to predict the identity system referenced in the SOAP/XML message should reference tokens who direction is supported by policy
Law 5: Pluralism of Operators and Technologies
Description: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers
Implication: This law acts as a direct design requirement for identity information in Web Services
Law 6: Human Integration
Description: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks
Implication: Not directly applicable since web services do not typically have GUIs; however composeable nature of SOAP and WS-* protocols means that advances in HCI security may be able to be supported these protocols in future
Law 7: Consistent Experience Across Contexts
Description: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
Implication: As systems are integrated across organizational and technical boundaries, there security tokens have to deal with conflicting standards and constraints. WS-Trust allows for client using Kerberos, SAML, X.509, and Username/password to exchange their tokens and connect to other remote services thus isolating the client (service requester) from these protocols
Comments