1. James first nails it around Microsoft's inherent advantage of shipping technology as part of the operating system. In other words, at no additional charge. Euphemistically called "bundling" by the DOJ. (Emphasis is mine)
For example, if Progressive wanted to federate with Citigroup, they would probably do so using SAML and a lot of the discussions in terms of the Liberty Alliance have targeted this demographic. One should ask themselves how federation would change if Progressive wanted to federate with all of their other business partners, most of which don't have dedicated IT staff nor the budget to buy separate standalone products and instead prefer to see federation support built into products they already use such as the operating system. This is where WS-Federation in terms of implementation will win hands down over SAML.
2. Microsoft's rose-colored glasses around XrML is preventing them from actively embracing XaCML. (Emphasis is mine)
The one thing I see that SAML 2.0 supports that no one is talking about in the WS-Federation camp is in support of XACML. The WS-Federation camp is overhyping identity while avoiding any discussions as to the problem space enterprises face related to disparate authorization models. To be fair, the SAML community has defined the specification but none of the vendors who support SAML actually bridge SAML to XACML.
#1 enables Microsoft to eventually win the battle that James discusses. #2 could potentially hold us ("the user") all back - I'm not really seeing any XrML-based products or interfaces for Windows Server & IIS being cranked up...
Technorati Tags:
authorization, federation, Active Directory Federation Services, WS-*, SAML,
No comments:
Post a Comment