(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

1. SAML 2.0 browser single sign-on 65 (75.6%)
2. SAML 1.x browser single sign-on 46 (53.5%)
3. Other uses of SAML 19 (22.1%)
4. OpenID 16 (18.6%)
5. Other (see detail below) 13 (15.1%)
6. WS-Federation 10 (11.6%)
7. SPML 7 (8.1%)
8. WS-Trust 6 (7.0%)
9. XACML 5 (5.8%)
10. 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):

NOTE: 82 respondents to this question

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

1. Single sign-on to partner site 61 (73.5%)
2. 2 (TIE) - Internal cross-domain SSO 45 (54.2%)
3. 2 (TIE) - Integrating hosted services 45 (54.2%)
4. Attribute exchange 41 (49.4%)
5. Securing collaboration 37 (44.6%)
6. Federated identity provisioning 30 (36.1%)
7. For clients of SaaS app 20 (24.1%)
8. For revenue-generating online service 15 (18.1%)
9. Federated web services 11 (13.3%)
10. 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):

1. Specialty federation product 49 (59.8%)
2. Open-source toolkit 38 (46.3%)
3. Features incorporated directly into application (ERP, CRM, etc.) 13 (15.9%)
4. 4 (TIE) - Native capabilities of application server 9 (9.8%)
5. 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