It's hard to reference since most of the discussions on this topic are within the context of the proprietary identity/access management products on the market: IBM Tivoli, Netegrity, Novell, Sun all make products that enable the control from the enterprise side.
The issues the vendors are facing is integration with public systems like Passport or the Liberty Alliance, and more private federations based upon the same technologies.
Obviously, this is a big issue if you're involved in B2B and SOA.
Also, it's an area of focus for my companies competitive analysis research.
I suspect that resolution of these issues, will be a focus of enterprise computing and application development in the next few years.
It's Federation, not passports that matter
on
Microsoft Loses Passport
·
· Score: 3, Interesting
The real action is in federation and the ability of identity management systems to share trusts. Sure, it would be convenient if we didn't have to worry about the dozens of passwords we require for web sites we visit, including Slashdot. But that's a mere inconvenience compared to the issues faced by large organizations attempting to communicate together at an application level of trust.
There are many instances where two or more organizations would like to allow individual humans,software programs, and devices to communicate once they've been properly identified as 'authenticated' on each other's systems, but the costs of determining which of these entities have that appropriate authorization is too high for the recipient organizations. It's difficult enough to ensure that one's own people/programs have appropriate authorizations and privledges.
Sharing information on each of the potentially millions of instances requiring authentication becomes prohibitively complex and costly. Just managing a directory system that contained 1/4 million employees and a million other internal objects is a huge undertaking. Adding even a fraction of that number of directory objects from dozens of other entities is a burden unlikely to be acceptable.
Enter Federation. My organization trusts these individuals with the set of priviledges that our two organizations have agreed upon as apporpriate for our digital communications and my organization accepts the responsibility to maintain the integrity of our side of the connection. Our identity management system connects to yours and through the use of appropriate handshaking protocols (the federation part - over simplified, I know) demonstrates that trust exists and the communication can occur.
Now instead of maintaining a directory of millions of outside entities etc., we need only maintain a directory record for each approved communcations process.
These issues cross so many disciplines and technologies from e-mail and IM, to SOA and more, that federated trusts becomes necesary if the process is to work at all. Further discussion of this topic belongs, and probably already exists, in a another thread.
Slashdot Mirror
It's hard to reference since most of the discussions on this topic are within the context of the proprietary identity/access management products on the market: IBM Tivoli, Netegrity, Novell, Sun all make products that enable the control from the enterprise side. The issues the vendors are facing is integration with public systems like Passport or the Liberty Alliance, and more private federations based upon the same technologies. Obviously, this is a big issue if you're involved in B2B and SOA. Also, it's an area of focus for my companies competitive analysis research. I suspect that resolution of these issues, will be a focus of enterprise computing and application development in the next few years.
The real action is in federation and the ability of identity management systems to share trusts. Sure, it would be convenient if we didn't have to worry about the dozens of passwords we require for web sites we visit, including Slashdot. But that's a mere inconvenience compared to the issues faced by large organizations attempting to communicate together at an application level of trust.
There are many instances where two or more organizations would like to allow individual humans ,software programs, and devices to communicate once they've been properly identified as 'authenticated' on each other's systems, but the costs of determining which of these entities have that appropriate authorization is too high for the recipient organizations. It's difficult enough to ensure that one's own people/programs have appropriate authorizations and privledges.
Sharing information on each of the potentially millions of instances requiring authentication becomes prohibitively complex and costly. Just managing a directory system that contained 1/4 million employees and a million other internal objects is a huge undertaking. Adding even a fraction of that number of directory objects from dozens of other entities is a burden unlikely to be acceptable.
Enter Federation. My organization trusts these individuals with the set of priviledges that our two organizations have agreed upon as apporpriate for our digital communications and my organization accepts the responsibility to maintain the integrity of our side of the connection. Our identity management system connects to yours and through the use of appropriate handshaking protocols (the federation part - over simplified, I know) demonstrates that trust exists and the communication can occur.
Now instead of maintaining a directory of millions of outside entities etc., we need only maintain a directory record for each approved communcations process.
These issues cross so many disciplines and technologies from e-mail and IM, to SOA and more, that federated trusts becomes necesary if the process is to work at all. Further discussion of this topic belongs, and probably already exists, in a another thread.