I recently talked to a customer who uses a not-to-be-named payroll provider that happens to be the same one that Quest Software uses. I was mentioning to him how I hated the fact that I couldn't ever remember my password to logon to their web site to see my payroll statement and wouldn't this be a fabulous benefit of federation services - no more password to remember and forget! I could simply logon to the not-to-be-named payroll provider from my Quest desktop and voilà there's my payroll statement.
Well, imagine my excitement when the customer said to me "Oh, they support federation now"! Well, after some digging my excitement was quickly replaced with disbelief. The not-to-be-named payroll provider supports federation by requiring their customers to install Computer Associates eTrust SiteMinder product and configuring it in a particular way in order to get the federated single sign-on benefit. What if I had a different product that implements federation like Active Directory Federation Service, Oracle Identity Federation or BMC's Federated Identity Manager? Apparently, I'm on my own in that circumstance as only the CA product is supported.
Federation is supposed to be about interoperability between dissimilar products, environments and even differing standards like SAML, WS-* and Kerberos. There are a lot of vendors in this space spending time on interoperability workshops and working on standards together to achieve this goal so customers will have a choice of products.
Defining a product requirement and requiring customers to purchase a particular product doesn't make a standard and it certainly isn't the intent of federation.
Technorati Tags: SAML, eTrust, federation, identity management, SiteMinder, kerberos, WS-*
IS4U: FIM 2010: SSPR with one-way trust
4 hours ago