Felhaszáló központú és föderatív azonosítási megoldások webalkalmazásokban. Szalai Ferenc Web Service Bricks

Átírás

1 Felhaszáló központú és föderatív azonosítási megoldások webalkalmazásokban Szalai Ferenc Web Service Bricks

2 Mi a probléma?

3 a felhasználó érték

4 mindannyian az adatbázis marketing üzletben vagytok

5

6 a weboldalak minél többet szeretnének tudni felhasználóikról

7 a felhasználók csak annyit akarnak elárulni, amennyit mindenképen szükséges

8 a felhasználót azonosítani kell

9 a felhasználóról adatok kellenek

10 (lehetőleg minél több, hagy örüljenek a marketingesek)

11

12

13 és meg a ismerőseidet és bekattintgathatod

14 Hol itt a probléma?

15 a felhasználók nem szeretik

16 felhasználók 33%-a egy elmegy, a egy új regisztrációs formot lát, 20%-a nem akar emlékezni egy újabb felhasználónév jelszó pára (ask500peope.com survay 2007 október)

17 a felhasználók hazudnak

18 központosított

19 alkalmazás központú

20 a fehasználónév jelszó nem biztosít semmit

21 adatbázis bejegyzés vagy

22 egyszerűbb

23 megbízhatóbb

24 Felhasználóközpontú Felhasználó dönt, milyen információt ad ki magáról kinek Csak azt az információt kell kiadni, ami feltetlenül szükséges a szolgáltatás igénybevételéhez. A felhasználó dönt, hogy milyen harmadik szervet von be a műveletekbe (pl.: IdP). Pseudonymity Független a technológiától és annak üzemeltetőjétől Adathalászat mentes (Anti-phishing) Minden körülmények között hasonló élményt nyújt a felhasználónak.

25

26 Szereplők

27 Service Provider akaromazadatod.hu (Felhasználja az infomációt) Identity Provider nalamvanazadatod.hu (Rendelkezik az információval) Identity Agent - envagyokaz.hu (Szabályozza a hozzáférész az adatokhoz)

28 IdP token RP token

29 Rendezők

30 Eredetileg Liberty Alliance OpenID Gyártói konzorcium Blogoszféra és open Internet fejlesztés Microsoft- és Information felhasználócards központú közösség KIalakíás Felhasználók Megvalósítás Web Services a federated személyazonossághoz Pénzügy, egészségügy, államigazgatás, utazás OpenLiberty, Novell, Sun, IBM, Oracle, HP, CA, Nokia Egyszerű URL-alapú hitelesítés Több ezer weboldal LiveJournal, Technocrati AOL, MS Nyílt forrású bővítmények, Apache, Drupal, Wordpress, MediaWiki FelhasználóWindows Vista MS Cardspace, Higgins, Ping, alapú személy- IE7 Pamela Project, azonossági Sxip szolgáltatások

31

32

33 OpenID Azonosító: URL ( Az azonosítás nem automatikus, azt minden esetben SP oldalról kezdeményezni kell. Nincs bizalmi viszony az IdP és SP között. Attribútumcsere szabványos 2.0 óta. Nagy szolgáltatók támogatják: AOL, Yahoo, Google, MS, stb. Független IdP-k pl.: myopenid.com OpenID IdP-k integrációs pontok más technológiákkal. Rengeteg probléma vár megoldásra pl.: phishing

34 Hogy működik?

35 1. azonosító

36 URL

37 XRI =Mary.Jones

38

39

40

41 2. meg kell találni az OpenID IdP-t (szervert)

42

43 URL esetén: HTTP header X-XRDS-Location:

44 XRD példa <xrds:xrds xmlns:xrds="xri://$xrds" xmlns:openid=" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type> <Type> <Type> <Type> ishing resistant</ Type> <Type> <URI> <LocalID> </Service> </XRD>

45 3. asszociáció: shared secret megegyezés, kulcscsere (HMAC-SHA1, HMAC-SHA256)

46 4. azonosítás kérés: HTTP redirect (openid.return_to paraméter)

47 5. IdP login kepernyő (vagy nem)

48 6. (opcionális) felhasználó nyilatkozik, hogy engedi-e az RP-nek az azonosítást és ha igen ilyen attribútumokat kaphat meg

49 7. azonosítási kérésre válasz: HTTP redirect (openid.claimed_id) aláírás

50 És mi van az attribútumokkal?

51 OpenID Attribute Exchange 1.0

52 openid.ns.ax= openid.ax.mode=fetch_request openid.ax.type.fname= openid.ax.type.gender= openid.ax.type.fav_dog= e_dog openid.ax.type.fav_movie= ite_movie openid.ax.count.fav_movie=3 openid.ax.required=fname,gender openid.ax.if_available=fav_dog,fav_movie openid.ax.update_url= transaction_id=a6b5c41

53 openid.ns.ax= openid.ax.mode=fetch_response openid.ax.type.fname= openid.ax.type.gender= openid.ax.type.fav_dog= e_dog openid.ax.type.fav_movie= ite_movie openid.ax.value.fname=john Smith openid.ax.count.gender=0 openid.ax.value.fav_dog=spot openid.ax.count.fav_movie=2 openid.ax.value.fav_movie.1=movie1 openid.ax.value.fav_movie.2=movie2 openid.ax.update_url= transaction_id=a6b5c41

54 Integráció

55 RP oldal sok jó IdP oldal kevés Python: python-openid (JanRain) Django:

56 Huston we have a problem

57 NO TRUST!

58 mindenki IdP akar lenni

59 adathalászat

60 Mi lesz a nem humanoidokkal?

61 Tapasztalatok

62 2007 május - szeptemer 6730 felhasználó 448 OpenID (< 10 db magyar, külföldiek kb. 23%-a) 309 myopenid.com

63 attribute exchange támogatást nem lehet feltételezni az IdP-éknél

64 cím attribútum nem megbízható, de nagyobb valószínűséggel élő

65 kicsit másképpen

66 föderatív megoldások

67 nagyvállalati igények

68

69 nem csak Web Wan a Wilágon!

70 InfoCard/CardSpace Felejtsük el végre a jelszót! A valós személyazonosító kártyákat mintázza. Minden kártyának globális egyedi azonosítója van. Saját kibocsátású (Self-issued) és IdP által kibocsátott kártyákat is kezel. WS-* protokollokra és SAML igazolásokra épül. Nem csak Windows!

71

72

73 <form method="post" action=" id="infocard form" class='noline'> <input type="hidden" name="tid" value="da2363ec" /> <input type="hidden" name="resume_action" value="signin_password" /> <input type="image" id="infocard logo button" value="choose an Information Card" src=" <label for='infocard logo button'><a id="infocard label" onclick="document.getelementbyid('infocard form').submit(); return false;">sign in with an Information Card</a></label> <noscript> <OBJECT type="application/x informationcard" name="xmltoken" class="skip"> <PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion"> <PARAM Name="issuer" Value=" <PARAM Name="requiredClaims" Value=" lidentifier"> <PARAM Name="optionalClaims" Value=" </OBJECT> </noscript> <input type="hidden" name="token" value="414c702680f1884dcd1cac62f94a2bd d3" /></form>

74 WS-* WS-Policy: kommuniáció előfeltételeinek meghatározása (algoritmus, elvárt tokenváltozat stb.) WS-Trust: fő komponense az STS (Security Token Service) általános keret (Username, Kerberos, X509, stb.) tokenek biztonságos továbbítására WS-Federation: AuthN, AuthZ, Attribútum, Pseudonym szolgáltatások integrációja WSTrust alapon

75 SAML 2.0 Security Assertion Markap Language Igazolások (assertion) leírásának nyelve IdP és RP közötti protokoll-profilok kire vonatkozik?, kinek szól?, meddig érvényes?, attribútumok pl.: WebSSO Bindings: hogyan kell SAML igazolást küldeni pl. SOAP üzenetben Metadata: az IdP és RP leírása XML-ben Profilok: az elfogadott attribútumok specifikációja

76 Explicit TRUST szükséges!

77 Hogy működik?

78

79

80

81 Interoperability

82

83 Mit csinálunk?

84 nyílt forrású SAML 2.0 alapú felhasználó központú IdP-t

85 Kinek?

86 lusta programozónak és magunknak

87 Miért?

88 mert meg tudjuk csinálni

89 meg mert 1-nél több alkalmazást fogunk fejleszteni a közel jövőben és nem akarunk a google, inda stb. sorsára jutni

90 Hogyan?

91 Python, Django

92 SAML 2.0: Lasso (C, wrappers: python, php, java, perl) SAML 2.0 IdP, SP

93 PyInfocard:

94 fő üzenet

95 legyél RP!

96 hova tovább, hovatovább?

97 Identity 2.0

98 Mi szeretnénk, mi várható?

99 1. egyre kevesebb jelszó

100 2. gazdag, hordozható profilok

101 3. hordozható azonosítók

102 4. működő, finoman hangolható delegáció

103 5. reputáció szolgáltatók

104 6. személyazonosság (identity) szolgáltatások

105 kérem kapcsolja ki