Tuesday, May 18, 2010
Thoughts on SPML 3.0
Much of the discussion around identity provisioning is centered on employees where the authoritative source of data is usually an HR system. As the conversation moves away from the employee-demographic to business partners, several additional things need to be considered. I am glad to see that SPML is not on life support and that the identity community is committed to improving the OASIS SPML specification. I figured I would share a few thoughts on what I would like to see SPML 3.0 address...
Metadata
Currently, the SPML specification describes the operations that can occur against a given user schema but does not define either a model for any particular user nor even provides a mechanism to discover supported models. If companies wanted to expose their SPML services to their business partners, they would need to first manually define what the user model looks like and then duplicate the information within each implementation. This approach is fragile and error-proven.
The ability for one identity management tool to understand the user model that another identity management tool is best supported by developing interoperable metadata exchange capabilities. At some level, the SAML specification supports this construct and it would be good if SPML supported something similar.
Virtualization
Their is an implied coupling between SPML operations and the underlying data store. For example, if you wanted to store a person and an organization, you would need to potentially invoke this as two separate operations. More importantly, one of the general principles of a service-oriented architecture is to avoid coupling, it would be bad form for you to describe your internal data structure externally and therefore a virtualization layer is needed.
Many enterprises will be coerced into thinking that virtualization is solely a construct that separate the SPML gateway from its underlying store. Others could argue that virtualization in this regard really shouldn't be a separate product but something baked into each implementation especially to aid in describing the metadata requirements. Either way, the need for provisioning to operate supporting coarse-grained constructs that aren't one-to-one with the underlying implementation is a key consideration.
Entitlements
Imagine a scenario where salesforce.com exposes a SPML gateway to allow its clients to support provisioning and de-provisioning activities. This begs several questions related to entitlements such as can Client A provision an account that allows access to Client B's data? We all know the contractual answer, but in terms of how this is enforced within current SPML solutions is all over the place. Anytime, you need to support multitenancy constructs this issue is going to raise its head.
One can think about whether SPML implementations support industry specifications such as xACML but that is an oversimplification. Again, since SPML only defines the operations but doesn't define a common way to even understand who is making the request nor having any understanding of the target resource, an entitlements model is left up to the discretion of the implementer and may introduce additional security risks.
Minimally, it would be great if products defined the right extension points such that if an end-customer wanted to do something other than deferring to an XACML-based they could pull out a trusty SDK an implement a few nterfaces in order to make this happen.
Attestation
The requirement for an organization to provide attestation capabilities for whomever accesses their IT ecosystem is at the center of many organizational SoX controls. While enterprises can be enterprisey in their thinking and insular in their focus, shouldn't they also be thinking about how their business partners attest to access to their systems as well? Within an IT ecosystem, your systems may not only be under SoX scope for you but also your business partners as well and having the right interfaces to support attestation in a federated manner is becoming increasingly important.
Attestation standards usually specify standards of reporting. Within a federated provisioning model, this include exposing statistics on various provisioning workflows that include success/failure rates filtered for a given partner/call. It may also define obligations analogous to how XACML defines this notion where certain interactions with partners or transaction types may have additional logging/auditing/alerting requirements around them. For example, if I work for a major Wall Street Bank and I need access to a trading platform, one may want to define a different level of auditing if I am requesting access to a foreign currency trading platform than other levels of access since the risk profile is different.
Each business will have their own take on what needs to be audited but we need a general way to record the obligations of different parties in a federated provisioning scenario. This all should be driven by standards.
| | View blog reactionsMetadata
Currently, the SPML specification describes the operations that can occur against a given user schema but does not define either a model for any particular user nor even provides a mechanism to discover supported models. If companies wanted to expose their SPML services to their business partners, they would need to first manually define what the user model looks like and then duplicate the information within each implementation. This approach is fragile and error-proven.
The ability for one identity management tool to understand the user model that another identity management tool is best supported by developing interoperable metadata exchange capabilities. At some level, the SAML specification supports this construct and it would be good if SPML supported something similar.
Virtualization
Their is an implied coupling between SPML operations and the underlying data store. For example, if you wanted to store a person and an organization, you would need to potentially invoke this as two separate operations. More importantly, one of the general principles of a service-oriented architecture is to avoid coupling, it would be bad form for you to describe your internal data structure externally and therefore a virtualization layer is needed.
Many enterprises will be coerced into thinking that virtualization is solely a construct that separate the SPML gateway from its underlying store. Others could argue that virtualization in this regard really shouldn't be a separate product but something baked into each implementation especially to aid in describing the metadata requirements. Either way, the need for provisioning to operate supporting coarse-grained constructs that aren't one-to-one with the underlying implementation is a key consideration.
Entitlements
Imagine a scenario where salesforce.com exposes a SPML gateway to allow its clients to support provisioning and de-provisioning activities. This begs several questions related to entitlements such as can Client A provision an account that allows access to Client B's data? We all know the contractual answer, but in terms of how this is enforced within current SPML solutions is all over the place. Anytime, you need to support multitenancy constructs this issue is going to raise its head.
One can think about whether SPML implementations support industry specifications such as xACML but that is an oversimplification. Again, since SPML only defines the operations but doesn't define a common way to even understand who is making the request nor having any understanding of the target resource, an entitlements model is left up to the discretion of the implementer and may introduce additional security risks.
Minimally, it would be great if products defined the right extension points such that if an end-customer wanted to do something other than deferring to an XACML-based they could pull out a trusty SDK an implement a few nterfaces in order to make this happen.
Attestation
The requirement for an organization to provide attestation capabilities for whomever accesses their IT ecosystem is at the center of many organizational SoX controls. While enterprises can be enterprisey in their thinking and insular in their focus, shouldn't they also be thinking about how their business partners attest to access to their systems as well? Within an IT ecosystem, your systems may not only be under SoX scope for you but also your business partners as well and having the right interfaces to support attestation in a federated manner is becoming increasingly important.
Attestation standards usually specify standards of reporting. Within a federated provisioning model, this include exposing statistics on various provisioning workflows that include success/failure rates filtered for a given partner/call. It may also define obligations analogous to how XACML defines this notion where certain interactions with partners or transaction types may have additional logging/auditing/alerting requirements around them. For example, if I work for a major Wall Street Bank and I need access to a trading platform, one may want to define a different level of auditing if I am requesting access to a foreign currency trading platform than other levels of access since the risk profile is different.
Each business will have their own take on what needs to be audited but we need a general way to record the obligations of different parties in a federated provisioning scenario. This all should be driven by standards.
