Monday, January 22, 2007
Identity Propagation
Gunnar Peterson outlined a couple of scenarios in which need deeper analysis...
The question of depth of propagation is an important topic that should be discussed by others. In the scenario you outlined, it assumes that all downstream interactions are 100% controlled by the enterprise. What if the enterprise decides on a strategy of SOA where they consume services outside their enterprise? Of course, identity propagation becomes more important. One of course needs to ask themselves whether using a pooled credential is wise (acknowledging problems with auditability) or whether they need to actually propagate deeper. I would say this should be left up to the discussion of the enterprise and their own policies.
The untold story however is that many enterprises can't decide anything about depth of propagation because the standards don't yet exist to support it. Maybe it is because industry analysts aren't yet asking vendors about this problem space or maybe it is because it is a lot of work on the part of standards bodies such as Liberty Alliance and there are more important things to discuss such as the flavor of one's coffee.
SAML would be a good specification to start figuring out how not only identity propagation could work from web application all the way down to the relational database one stored their information in. Of course, someone would need to figure out the JDBC/SAML relationship and how to make identity-based pooling a reality.
Provisioning doesn't have to be deep if I can do everything at runtime. For example, imagine a situation where I didn't have to pre-register to access my bank to do wire transfers but could at runtime use the credentials of my employer who would tell them based on prior established trust relationships that I am me but that I am also authorized to make certain transactions. Oops, this would require SAML/XACML authorization discussions that no one really wants to talk about.
I absolutely believe that everyone should read Mark's thoughts but my original response stated that XACML should be built into applications and not simply proxied by an intermediary. I would like to see industry analysts ask CRM, BPM and ECM product vendors where on their roadmap is XACML support as making it part of an application provides functionality that can be used for deeper attestation constructs which cannot be done if using intermediary approaches.
I want to jump out the nearest window with all these consumerish scenarios where the conclusion that authorization has to occur from the same source as authentication. Let me provide an example in the real world that hopefully will invalidate this type of thinking.
Consider a scenario where a Blackhawk Helicopter fell out of the sky and landed in my basement and crushed my computer so I can no longer blog. Of course, I would like to submit a claim to my favorite insurance company. I pull out the handy dandy Yellow Pages and find a total of three contractors each with their own specialization. All three contractors work for Handyman Matters. I would like for Handyman matters to not only provide strong proof in terms of authentication that they say who they are but to also check that they are licensed to do home repair in my state. Of course, I wouldn't trust any contractor who says that they are licensed without validating it so I would want the State of Connecticut to provide authorization in terms of not only whether their license is valid but that they can do certain types of work. Likewise, I would also want whatever insurance carrier they used for workers compensation to also perform authorization that their insurance is current before they initiate anything in my basement.
Having authorization come from different sources in many circumstances provides more credibility than from situations originated by authentication alone. The key is that we have to move the conversation away from stupid consumerish discussions and talk about how business works in the real world. Of course, my scenario is 1000% fictitious but hopefully folks can get the general idea. By trusting the insurance company over the contractor who provided the credential provides me with reduction in risk. The same thing can be said of the State of Connecticut.
One question for you Gunnar, what would it take to get the folks participating on OpenID to also embrace secure coding practices?
| | View blog reactions- So one question, is how far do you propagate the user's credentials? Do you keep a record on each user in all six systems?
The question of depth of propagation is an important topic that should be discussed by others. In the scenario you outlined, it assumes that all downstream interactions are 100% controlled by the enterprise. What if the enterprise decides on a strategy of SOA where they consume services outside their enterprise? Of course, identity propagation becomes more important. One of course needs to ask themselves whether using a pooled credential is wise (acknowledging problems with auditability) or whether they need to actually propagate deeper. I would say this should be left up to the discussion of the enterprise and their own policies.
The untold story however is that many enterprises can't decide anything about depth of propagation because the standards don't yet exist to support it. Maybe it is because industry analysts aren't yet asking vendors about this problem space or maybe it is because it is a lot of work on the part of standards bodies such as Liberty Alliance and there are more important things to discuss such as the flavor of one's coffee.
SAML would be a good specification to start figuring out how not only identity propagation could work from web application all the way down to the relational database one stored their information in. Of course, someone would need to figure out the JDBC/SAML relationship and how to make identity-based pooling a reality.
- From a IDM standpoint how complex do you want your provisioning to be?
Provisioning doesn't have to be deep if I can do everything at runtime. For example, imagine a situation where I didn't have to pre-register to access my bank to do wire transfers but could at runtime use the credentials of my employer who would tell them based on prior established trust relationships that I am me but that I am also authorized to make certain transactions. Oops, this would require SAML/XACML authorization discussions that no one really wants to talk about.
- Mark O'Neill weighs in on authorization in general, XACML in particular and how Vordel's products help you deal with it.
I absolutely believe that everyone should read Mark's thoughts but my original response stated that XACML should be built into applications and not simply proxied by an intermediary. I would like to see industry analysts ask CRM, BPM and ECM product vendors where on their roadmap is XACML support as making it part of an application provides functionality that can be used for deeper attestation constructs which cannot be done if using intermediary approaches.
- A combination of the patterns needs to limit the amount of authentication and instead use previously authenticated attributes to authorize access.
I want to jump out the nearest window with all these consumerish scenarios where the conclusion that authorization has to occur from the same source as authentication. Let me provide an example in the real world that hopefully will invalidate this type of thinking.
Consider a scenario where a Blackhawk Helicopter fell out of the sky and landed in my basement and crushed my computer so I can no longer blog. Of course, I would like to submit a claim to my favorite insurance company. I pull out the handy dandy Yellow Pages and find a total of three contractors each with their own specialization. All three contractors work for Handyman Matters. I would like for Handyman matters to not only provide strong proof in terms of authentication that they say who they are but to also check that they are licensed to do home repair in my state. Of course, I wouldn't trust any contractor who says that they are licensed without validating it so I would want the State of Connecticut to provide authorization in terms of not only whether their license is valid but that they can do certain types of work. Likewise, I would also want whatever insurance carrier they used for workers compensation to also perform authorization that their insurance is current before they initiate anything in my basement.
Having authorization come from different sources in many circumstances provides more credibility than from situations originated by authentication alone. The key is that we have to move the conversation away from stupid consumerish discussions and talk about how business works in the real world. Of course, my scenario is 1000% fictitious but hopefully folks can get the general idea. By trusting the insurance company over the contractor who provided the credential provides me with reduction in risk. The same thing can be said of the State of Connecticut.
One question for you Gunnar, what would it take to get the folks participating on OpenID to also embrace secure coding practices?
