(May 5, 2009)

This survey assumed the following definition of identity federation: Digitally trusting authentication, authorization, and/or other identity information coming from other security domains, with cross-domain single sign-on being a well-known example. 112 respondents began the survey; 103 respondents completed the survey. Responses appear in bold after the question, and have been reordered, where applicable, in descending order of response. The raw results are also available in full here.

1. Does your organization support identity federation? 87 yes (81.3%); 20 no (18.7%)

2. Which of the following do you support with your federation deployments (check all that apply)? view graphic

SAML 2.0 browser single sign-on 65 (75.6%)
SAML 1.x browser single sign-on 46 (53.5%)
Other uses of SAML 19 (22.1%)
OpenID 16 (18.6%)
Other (see detail below) 13 (15.1%)
WS-Federation 10 (11.6%)
SPML 7 (8.1%)
WS-Trust 6 (7.0%)
XACML 5 (5.8%)
Information Card 3 (3.5%)

OTHER DETAILED RESPONSES: 1) CAS (Central Authentication Service); 2) custom, in-house; 3) PAPI (a pre-SAML proprietary protocol); 4) Shibboleth; 5) Windows Live ID; 6) A-Select; 7) Biometric Speaker Verification; 8) POST Profile; 9) PKI FBCA and FiXs; 10) browser SSO via Pubcookie; 11) Proprietary formats required by our customer credit unions; 12) Facebook; 13) RFID; 14) Shibboleth; 15) Digital certificates---Federal Bridge Certificate Authority; and 16) ADFS.
NOTE: 86 respondents to question

3. How many identity-based federated relationships do you have?
A. As a Service Provider / Relying Party?
a. One 7
b. Two to Ten 42
c. More than Ten 21

B. As an Identity Provider?
a. One 11
b. Two to Ten 34
c. More than Ten 27

NOTE: 85 respondents to question

4. Among the following models for establishing federated relationships, select the ones that best describe your approach and the role(s) you operate in (select any that apply):

	Bilateral/Explicit Partnering	Circles of Trust (tightly coupled)	Multi-Party Federations (loosely coupled)	Internet Scale/Dynamic Federation
As an Identity Provider	38	35	22	8
As a Service Provider	29	34	18	7
As a Circle of Trust "Operator"	8	19	7	4
As a Federation "Operator"	7	17	12	3

NOTE: 82 respondents to this question

5. What use case(s) best describe your identity federation deployments (please select all that apply):

Single sign-on to partner site 61 (73.5%)
2 (TIE) - Internal cross-domain SSO 45 (54.2%)
2 (TIE) - Integrating hosted services 45 (54.2%)
Attribute exchange 41 (49.4%)
Securing collaboration 37 (44.6%)
Federated identity provisioning 30 (36.1%)
For clients of SaaS app 20 (24.1%)
For revenue-generating online service 15 (18.1%)
Federated web services 11 (13.3%)
Other (see detail below): 6 (7.2%)

OTHER DETAILED RESPONSES: 1) cross domain SSO service for citizen-oriented services from public sector agencies; 2) computer door lock; 3) user convenience and avoiding the creation/management of PII; 4) combined logical and physical access authentication; and 5) business messages (eg. financial aide and transcripts)
NOTE: 83 respondents to this question

6. Are you federating using (please select all that apply):

Specialty federation product 49 (59.8%)
Open-source toolkit 38 (46.3%)
Features incorporated directly into application (ERP, CRM, etc.) 13 (15.9%)
4 (TIE) - Native capabilities of application server 9 (9.8%)
4 (TIE) - Other (see detail below): 8 (9.8%)

OTHER DETAILED RESPONSE: 1) compatible with COT products as well; 2) simpleSAML.php; 3) web widgets; 4) purpose built; 5) Shibboleth is our open source federation product; 6) CAS; 7) Shibboleth 1.3 and 2.x; 8) combination of productions; 9) our patented SDK; 10) simpleSAMLphp and PingFederate; 11) Sun’s OpenSSO product; 12) custom implementation; and 13) self-written federation support.
NOTE: 82 respondents to this question

7. What benefits have you observed from your identity federation deployments (please select all that apply):

Single sign on benefits 72 (87.8%)
Enhanced user experience 53 (64.6%)
Greater security 52 (63.4%)
Reduced costs to support partners 44 (53.7%)
Realization of new business opportunities 36 (43.9%)
Reduced internal production costs 32 (39%)
Greater privacy 30 (36.6%)
Other (see detail below) 8 (9.8%)

OTHER DETAILED RESPONSE: 1) richer identity for more appropriate access management; 2) new international partnerships; 3) public sector agencies can standardize on a common eID for authentication; 4) centralized management; 5) increased use of applications (easier to log on), easier to implement dual-factor authentication for ASPs; 6) too early to say definitively; 7) too early to tell; and 8) reduction in applications which create an isolated internal account management system.
NOTE: 82 respondents to question

8. What problems have you encountered with your identity federation deployments (please select all that apply):

Potential partners lack identity federation technology 64 (78%)
Lack of experience in implementing federation technology 54 (65.9%)
User confusion 32 (39%)
Challenges to realizing new business opportunities 14 (17.1%)
Higher costs to support partners 10 (12.2%)
Higher internal production costs 7 (8.5%)
Other (see detail below) 5 (6.1%)
Weakened privacy 1 (1.2%)
Weakened security 0

OTHER DETAILED RESPONSE: 1) bookmarking of session coupled login pages; 2) improving local identity management operations to meet Level of Assurance requirements is hard; 3) low user uptake; 4) lack of standards in how to handle single log-out, session management, federation only solves for authentication, we still have to solve difficult authorization probles; 5) performance; 6) buy-in to outsourcing traditional in-house tasks; and 7) interoperability challenges especially with OpenID and open source toolkits.
NOTE: 82 respondents to question

9. Anything else that you would like to share to enhance our understanding of your approach to identity federation?

Need to find ways to make people realize it a business partnership first before technical; more emphasis gets placed on technical, but should be placed on business;
"Trust" is important if the federation is to serve unaffiliated entities. The FO as "trust broker" is a critical role in order to scale "trust.";
I have only selected what is in production today. Later this year our federation is being extended with SOAP-based web services secured by SAML 2.0 tokens - and the ability for local organizations to use their own IdP toward the federation while also using the IdP for other purposes (i.e. SaaS apps, bilateral federation agreements etc.);
attribute release policies are hard. consulting the local consumer pretection agency for guide lines for negotiating ARPs has been of good help. Also prof (expencive) legal help has been worth the money.;
would be helpful to see more use cases, not sure where to find them. Also use cases coupled with technologies/companies/services and links to people/companies that can help implement?;
Microsoft now offers Federation Services in W2K3 Server which looks promising.;
Had problems understanding the matrix in question 4. Question 7 and 8 assumes the federation deployment changed an existing partnership, but before our SSO-service, we didn't have any partnerships that became either cheaper or more expensive.;
All the details about our federation http://www.switch.ch/aai/;
We believe that federation is best implemented on well-established administrative boundaries.;
Federation has been extremely helpful and after a few years at this we are hitting our stride and doing federations quickly at least with vendors who are familiar with federation. Would be great if Liberty spent more time on solving cross-domain authorization problems.;
We are trying to be an RP for SAML and OpenID and Information Cards. That is nearly impossible to achieve given the state of toolkits today.; and
There is a huge opportunity here for banks to offer services via an Identity Assurance Federation using the Liberty Alliance's Identity Assurance Framework. I have spoken extensively on this topic for years.

Browser not supported