Federated Identity for Cloud Computing and Cross-organization Collaboration Steve Moitozo Strategy and Architecture SIL International 20110616.2 (ICCM)
Follow me @SteveMoitozo2 2
Huge Claims You want federated identity, you just might not know it yet. streamline the way you integrate your Web applications change the way you think about partnerships and cloud services 3
About SIL Founded in 1943 Focused on language development for minority languages Linguistic investigation of over 2,590 languages in 100 countries 5,500 staff from 60 countries World authority in cataloging of languages Publisher of Ethnologue: Languages of the World 4
About SIL Registration Authority for the ISO 639-3 standard Produced over 37,500 publications since 1943 Member of Micah Network and Forum of Bible Agencies Partner with over 120 organizations Wycliffe Global Alliance is our primary partner 5
What are the problems? Collaborating across organizational boundaries is hard because of authentication Cloud services (SaaS & PaaS) are hard for the same reason Too many passwords Permissions build-up Passing passwords around ain't cool 6
Historical Progression Per app credentials Central passwords with LDAP, AD, Radius, or Kerberos Web single sign-on Federated authentication Federated authorization 7
Per App Credentials 8
Per App Credentials Each app sees password Potential for different user/pass No SSO Permissions build up 9
(Permission build up?) Joe works for department A Joe moves to department B Gets new permissions for the new job Keeps old permissions from the old job Unintentionally Poor process, or no process Intentionally Retained old responsibilities Phase out period 10
Centralized Credentials 11
Centralized Credentials Each app still sees password One user/pass Still no SSO 12
Web Single Sign-on 13
Web Single Sign-on No app sees password important for big/distributed organizations One user/pass Single sign-on 14
Why go beyond Web SSO? New possibilities New opportunities 15
Driving Beyond Web SSO Drivers Cloud Services Partnerships 16
Cloud Anyone? Google Apps? Box.net? Salesforce.com? Others? 17
Driver 1: Cloud services 18
Back to the Future 19
Back to the Future Cloud app sees password Potential for different user/pass Permission build up No SSO 20
Back to the Future 2 21
Back to the Future 2 Cloud app sees password One user/pass Still no SSO Password antipattern 22
(Anti-pattern?) It's a pattern that should be avoided 23
(Password Anti-pattern?) 24
(Password Anti-pattern?) Each app sees password Impersonation! Passing passwords around ain't cool 25
Scenario: Google Analytics 26
Scenario: Google Analytics Entitlement/Authorization Mismatch! Entitlement based on org affiliation Authorization based on Google identity What happens when the person is no longer affiliated (entitled)? What happens when the admin leaves? 27
Driver 2: Partnerships 28
Back to the Future, again 29
Scenario: Drupal Partnership 30
Scenario: Drupal Partnership Entitlement/Authorization mismatch! Entitlement for access based on partner affiliation Access based on Drupal identity Provisioning rules are because he said so What happens when the user leaves? What happens when the admin leaves? 31
Pain is your friend Are these scenarios painful? Are you doing this? (rhetorical) Pain tells us something is wrong. Pain makes us look for alternatives. 32
Federated Pattern Qualities Independence where required Operational (procedures, practices) Political (policies, governance) Technical (OS, app stack) Interoperation were beneficial 33
Federated Identity Organizations issue credentials for their own people Organizations manage the identity lifecycle for their own people SSO that interoperates with other organizations 34
Hype Cycle 35
Hype Cycle Projection 36
Navigating the Buzzwords OpenID OAuth SAML WS-* Shibboleth ADFS (Microsoft Active Directory Federation Service) IDP SP 37
Federated Authentication OpenID SAML (Shibboleth, SimpleSAMLphp) WS-Federation (ADFS) 38
OpenID vs SAML Organization-toindividual relationship B2C relationships Engaging the public Organization-toorganization relationship B2B relationships Partnerships Cloud 39
History of SAML and WS-Fed 40
SAML vs WS-Federation Similar in terms of function SAML is a self-contained specification WS-Fed specification depends on WS-Trust, WS-Policy, WS-SecurityPolicy, etc. SAML implementations tend to be self-contained as well WS-Fed implementations follow the dependancies SAML is simpler to understand and implement Simplicity is better for security, less potential for misconfiguration 41
Convergence 2007 SAML was the standard of choice for Research, Higher Ed, and Governments. 2009 Microsoft ADFS v2 passed Liberty Alliance SAML 2.0 interoperability tests 42
SAML Terminology IdP = identity provider Where the user is authenticated Authoritative source of identity attributes SP = service provider The Web application The resource that requires authentication 43
SP? 44
SAML eases the pain SAML for Web SSO SAML for Cloud-based services Google Salesforce.com Box.net SAML for Partnerships 45
SAML for SSO 46
SAML for the Cloud 47
SAML for Partnerships 48
SSO, Cloud & Partnerships! 49
Scenarios with SAML 50
Scenario: Google Analytics 51
Scenario: Google Analytics No mismatch Entitlement based on affiliation Authorization based on organization identity Person leaves, access denied No special administrator knowledge 52
Scenario: Drupal Partnership 53
Scenario: Drupal Partnership No more mismatch Entitlement for access based on partner affiliation Access based on partner identity Provisioning rules are based on partner affiliation User leaves, access denied No special administrator knowledge 54
(Wait, what about OAuth?) The auth is for authorization, not authentication OAuth is about data transfer Can be used to compliment any authentication scheme Mitigation for password anti-pattern 55
Federating with Partners Federation can still fail Requires trust Establishing trust is tricky Requires interoperable technology Lots of configuration options Standards and guidelines can help establish trust and ensure interoperation 56
Our Partnership 57
Introducing: Polder Consortium Establishing an environment of trust for information sharing across organizational boundaries 58
Polder Consortium Why Polder? Started in January 2011 Focused on the federated pattern Trust through common standards and practices Alignment with established standards and working groups (Internet2, Kantara Initiative, REFEDs, etc.) 59
Polder Consortium Outputs Implementation standards Operational policies Good practices Orientation and Getting Started documentation Not just Federated Identity Core Themes Federated Identity Web Services Federated Authorization 60
Getting Started Manage your identities centrally Get involved with Polder Consortium www.polderconsortium.org Implement a SAML IdP Shibboleth (Java) SimpleSAMLphp (PHP) Federate your Web apps (SSO) Federate with partners, cloud, or both 61
Huge Claims Revisited I told you you wanted federated identity! streamline the way you integrate your Web applications change the way you think about partnerships and cloud services 62
Summary SAML SSO Cloud Partnerships OpenID Individuals Engaging public Oauth Authorization Standards & Community Polder Consortium 63
Follow me @SteveMoitozo2 64
Reference URLs Standards & Good Practices http://www.polderconsortium.org http://kantarainitiative.org http://refeds.org SAML http://saml.xml.org http://shibboleth.internet2.edu http://simplesamlphp.org OpenID http://openid.net Oauth http://oauth.net 65