Saturday, December 09, 2006
Conor Cahill and Vendor Relationship Management
I want to kick myself for a previous posting in that my words didn't match my intent and I therefore was rewarded with a response that I already knew the answer to...
Conor Cahill previously responded to an inquiry on the importance of authorization within federated identity where I asked: Does Federated Identity sometimes require Federated Authorization?.
The question missed my own intent as it could be answered from a variety of perspectives. The architecture view says no which I already knew as identity can be decoupled from authentication which can be decoupled from authorization. Likewise, authorization mostly depends on strong authentication and authentication depends on identity. The perspective that I was actually seeking wasn't the architecture viewpoint but more of why industry thought leaders aren't talking about authorization and the over-abuse of the term identity management as a catch-all term and how these two problem spaces should become coupled in terms of the conversation.
Anyway, I do thank Conor for catching this error and for his effort hopefully can repay him by making a small contribution to a mutually agreed upon charity. Pat Patterson did a credible job of reading into my real intent for asking and responded here by mentioning the relationship between SAML and XACML in terms of a standard and how these two problem spaces could work together. I guess my real desire is to talk about convergence vs the conversation where identity is pretty much thought of as standalone in terms of the conversation to date (Yes, I am describing in terms of an emphasis not extreme, so please do twist).
It is good that he did admit that no commercial product seems to desire to close the gap. Maybe I am hoping that if others start talking about it that I can have the opportunity to procure the solution to several of the scenarios I have outlined over multiple blog entries. Likewise, I am glad that Conor at least acknowledged a situation where authorization is more than just simple attributes which calls out the need for XACML but left open an interesting point regarding protecting the resource. Some discussions on exactly how this should happen in a federation would make for an interesting conversation as on the surface it is a lot more difficult than it seems.
In reading Doc searls blog on Vendor Relationship Management where the goal is to bring a useful and productive balance of power between vendors and customers made me think of yet another way that federated identity may help converge both ideas.
Consider the problem space where an Architect who is employed by a Fortune 100 enterprise and he desires of his BPM vendors (Intalio, JBoss and Filenet), his ESB Vendors (Sonic, CapeClear, Iona) along with his ECM Vendors (Alfresco, Documentum and OpenText) to implement the XACML PEP specification as part of their product suite. Vendors will of course send lots of suits to meet with the Architect to have a nice cordial exchange of ideas. He may even be passively lulled into submission by being flattered by an invite to the vendors advisory board ignoring the fact that this is a distraction tactic that may not result in him getting the features he desires. Towards the end of the conversation, the vendor will ultimately say something similar to that your requirements for XYZ are interesting but you are the first customer to articulate them.
The Architect now has one of a few choices. He can sit passively hoping that the vendor will actually luck upon others also articulating the same problem to not only the vendor but the same folks within the vendor so that conversations can be connected or he can do his own homework and find peers who work in other Fortune 100 enterprises who also desire these same features and attempt to organize one big fat massive phone call so that the vendor can understand that others also desire these features. Wouldn't it be interesting if the architect via some federated identity mechanism could indicate not only his relationship with other architects but to also share a strong request to a resource (vendor) that they all collectively want them to enforce (aka implement) a common policy?
If vendor relationship management doesn't help solve for this problem that is repeated on a daily basis, then balance between vendor and customer may never be obtained. Hopefully, others who are talking about identity will talk about innovative usages of identity and solving problems that are meaningful outside of the vendor-oriented discussions that have been occuring. I will dismiss myself from this aspect as I have to work on figuring out better ways of articulating my thoughts so that the intent is properly conveyed. In the meantime, I am going to run into a wall while thinking about how Cardspace could work with Ruby on Rails...
| | View blog reactionsConor Cahill previously responded to an inquiry on the importance of authorization within federated identity where I asked: Does Federated Identity sometimes require Federated Authorization?.
The question missed my own intent as it could be answered from a variety of perspectives. The architecture view says no which I already knew as identity can be decoupled from authentication which can be decoupled from authorization. Likewise, authorization mostly depends on strong authentication and authentication depends on identity. The perspective that I was actually seeking wasn't the architecture viewpoint but more of why industry thought leaders aren't talking about authorization and the over-abuse of the term identity management as a catch-all term and how these two problem spaces should become coupled in terms of the conversation.
Anyway, I do thank Conor for catching this error and for his effort hopefully can repay him by making a small contribution to a mutually agreed upon charity. Pat Patterson did a credible job of reading into my real intent for asking and responded here by mentioning the relationship between SAML and XACML in terms of a standard and how these two problem spaces could work together. I guess my real desire is to talk about convergence vs the conversation where identity is pretty much thought of as standalone in terms of the conversation to date (Yes, I am describing in terms of an emphasis not extreme, so please do twist).
It is good that he did admit that no commercial product seems to desire to close the gap. Maybe I am hoping that if others start talking about it that I can have the opportunity to procure the solution to several of the scenarios I have outlined over multiple blog entries. Likewise, I am glad that Conor at least acknowledged a situation where authorization is more than just simple attributes which calls out the need for XACML but left open an interesting point regarding protecting the resource. Some discussions on exactly how this should happen in a federation would make for an interesting conversation as on the surface it is a lot more difficult than it seems.
In reading Doc searls blog on Vendor Relationship Management where the goal is to bring a useful and productive balance of power between vendors and customers made me think of yet another way that federated identity may help converge both ideas.
Consider the problem space where an Architect who is employed by a Fortune 100 enterprise and he desires of his BPM vendors (Intalio, JBoss and Filenet), his ESB Vendors (Sonic, CapeClear, Iona) along with his ECM Vendors (Alfresco, Documentum and OpenText) to implement the XACML PEP specification as part of their product suite. Vendors will of course send lots of suits to meet with the Architect to have a nice cordial exchange of ideas. He may even be passively lulled into submission by being flattered by an invite to the vendors advisory board ignoring the fact that this is a distraction tactic that may not result in him getting the features he desires. Towards the end of the conversation, the vendor will ultimately say something similar to that your requirements for XYZ are interesting but you are the first customer to articulate them.
The Architect now has one of a few choices. He can sit passively hoping that the vendor will actually luck upon others also articulating the same problem to not only the vendor but the same folks within the vendor so that conversations can be connected or he can do his own homework and find peers who work in other Fortune 100 enterprises who also desire these same features and attempt to organize one big fat massive phone call so that the vendor can understand that others also desire these features. Wouldn't it be interesting if the architect via some federated identity mechanism could indicate not only his relationship with other architects but to also share a strong request to a resource (vendor) that they all collectively want them to enforce (aka implement) a common policy?
If vendor relationship management doesn't help solve for this problem that is repeated on a daily basis, then balance between vendor and customer may never be obtained. Hopefully, others who are talking about identity will talk about innovative usages of identity and solving problems that are meaningful outside of the vendor-oriented discussions that have been occuring. I will dismiss myself from this aspect as I have to work on figuring out better ways of articulating my thoughts so that the intent is properly conveyed. In the meantime, I am going to run into a wall while thinking about how Cardspace could work with Ruby on Rails...
