Federated Identity for Cloud Computing and Cross-organization Collaboration

Transcription

1 Federated Identity for Cloud Computing and Cross-organization Collaboration Steve Moitozo Strategy and Architecture SIL International (ICCM)

2 Follow 2

3 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

4 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

5 About SIL Registration Authority for the ISO 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

6 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

7 Historical Progression Per app credentials Central passwords with LDAP, AD, Radius, or Kerberos Web single sign-on Federated authentication Federated authorization 7

8 Per App Credentials 8

9 Per App Credentials Each app sees password Potential for different user/pass No SSO Permissions build up 9

10 (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

11 Centralized Credentials 11

12 Centralized Credentials Each app still sees password One user/pass Still no SSO 12

13 Web Single Sign-on 13

14 Web Single Sign-on No app sees password important for big/distributed organizations One user/pass Single sign-on 14

15 Why go beyond Web SSO? New possibilities New opportunities 15

16 Driving Beyond Web SSO Drivers Cloud Services Partnerships 16

17 Cloud Anyone? Google Apps? Box.net? Salesforce.com? Others? 17

18 Driver 1: Cloud services 18

19 Back to the Future 19

20 Back to the Future Cloud app sees password Potential for different user/pass Permission build up No SSO 20

21 Back to the Future 2 21

22 Back to the Future 2 Cloud app sees password One user/pass Still no SSO Password antipattern 22

23 (Anti-pattern?) It's a pattern that should be avoided 23

24 (Password Anti-pattern?) 24

25 (Password Anti-pattern?) Each app sees password Impersonation! Passing passwords around ain't cool 25

26 Scenario: Google Analytics 26

27 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

28 Driver 2: Partnerships 28

29 Back to the Future, again 29

30 Scenario: Drupal Partnership 30

31 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

32 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

33 Federated Pattern Qualities Independence where required Operational (procedures, practices) Political (policies, governance) Technical (OS, app stack) Interoperation were beneficial 33

34 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

35 Hype Cycle 35

36 Hype Cycle Projection 36

37 Navigating the Buzzwords OpenID OAuth SAML WS-* Shibboleth ADFS (Microsoft Active Directory Federation Service) IDP SP 37

38 Federated Authentication OpenID SAML (Shibboleth, SimpleSAMLphp) WS-Federation (ADFS) 38

39 OpenID vs SAML Organization-toindividual relationship B2C relationships Engaging the public Organization-toorganization relationship B2B relationships Partnerships Cloud 39

40 History of SAML and WS-Fed 40

41 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

42 Convergence 2007 SAML was the standard of choice for Research, Higher Ed, and Governments Microsoft ADFS v2 passed Liberty Alliance SAML 2.0 interoperability tests 42

43 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

44 SP? 44

45 SAML eases the pain SAML for Web SSO SAML for Cloud-based services Google Salesforce.com Box.net SAML for Partnerships 45

46 SAML for SSO 46

47 SAML for the Cloud 47

48 SAML for Partnerships 48

49 SSO, Cloud & Partnerships! 49

50 Scenarios with SAML 50

51 Scenario: Google Analytics 51

52 Scenario: Google Analytics No mismatch Entitlement based on affiliation Authorization based on organization identity Person leaves, access denied No special administrator knowledge 52

53 Scenario: Drupal Partnership 53

54 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

55 (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

56 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

57 Our Partnership 57

58 Introducing: Polder Consortium Establishing an environment of trust for information sharing across organizational boundaries 58

59 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

60 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

61 Getting Started Manage your identities centrally Get involved with Polder Consortium Implement a SAML IdP Shibboleth (Java) SimpleSAMLphp (PHP) Federate your Web apps (SSO) Federate with partners, cloud, or both 61

62 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

63 Summary SAML SSO Cloud Partnerships OpenID Individuals Engaging public Oauth Authorization Standards & Community Polder Consortium 63

64 Follow 64

65 Reference URLs Standards & Good Practices SAML OpenID Oauth 65