Distributed Authorisation Infrastructures – X.509 Attribute Certificates and SAML

1. Stephen Farrell stephen.farrell@baltimore.ie Distributed Authorisation Infrastructures – X.509 Attribute Certificates and SAML

2. Authori[sz]ation • Operating Systems tend to have more-or-less consistent authorization models • Multics, Unix, Windows • All offer an authorization infrastructure (as do mainstream DBMSs) • Hasn’t really worked well for • Application layer authorisation when that doesn’t map nicely to OS entities • Distributed Systems • Despite some valiant attempts (e.g DCE, Corba)

3. Why this lack of infrastructure? • If we think in terms of subjects, objects and permissions • The subjects may not map well to OS accounts • The objects may not map well to any OS entity (mainly files) • The permissions may not map well to OS permissions (e.g. rwx insufficient) • Authorization infrastructures are complex • Relatively few applications required a real infrastructure • So application developers tend to either (somewhat artificially) try to map to OS or DB concepts or else invent their own solutions (over and over again)

4. Who tried what? • Military: Bell-LaPadula, MLS, various others • DCE: Authentication and Kerberos adata field and distributed ACLs • ECMA/SESAME:Kerberos/PKI + Privilege Attribute Certificates + PVF • Win2k: Similar to the above! • Corba: Secure IIOP, DCE RPC and/or SESAME

5. In-play authorisation infrastructures • X.509: Attribute Certificates • RFC 3281, ETSI-EESSI • SAML: XML authorization framework • XACML, XrML, Liberty

6. X.509 & PKIX • Originally part of X.500 (Directory) set of ISO/ITU-T standards • Defines Public Key Certificate (PKC) and Attribute Certificate (AC) data structures and semantics • Does not define supporting protocols • In 1995 an IETF working group (PKIX) was chartered to profile X.509 and to define supporting protocols • PKC profile RFCs 3279, 3280 • AC profile RFC 3281 • Management Protocols RFC 2510 (CMP), 2797 (CMC) • Certificate Status RFC 2560 (OCSP)

7. X.509 Attribute Certificates • Mainline description is based on RFC3281 • Exceptions as noted • Basic idea is to have an AC issuer who encodes privileges and other attributes of a “holder” into an attribute certificate • Looks almost the same as an X.509 PKC but with attributes instead of a public key • Well defined attributes include: Authentication Information, Identities (Access, Charging), Role, Group, Clearance • All this can also be done using PKC extensions but…

8. AC fields • ACs are signed; To-be-Signed structure: • version • holder • issuer • signature • serialNumber • attrCertValidityPeriod • attributes • extensions

9. Other AC concepts • Holder linkage • Audit identity extension • Targetting • Attribute encryption • Revocation • AA controls (for AC issuer’s PKC)

10. AC Usage for access control • Short-lived ACs are not unusual (minimum 1 second) • Entities involved: AC Issuer, AC Owner, AC verifier • Verifier “trusts” Issuer to only issue “good” ACs • Owner provides evidence (e.g. digital signature) of ownership • Verifier checks AC and (all being well) associates attributes with owner and makes an access decision

11. “Pull” Model AC-Issuer Actually could be “in front” of the real issuer 2. AC Request and Response AC-Holder AC-Verifier 1. Application Protocol (no ACs)

12. “Push” Model AC-Issuer 1. AC Request and Response AC-Holder AC-Verifier 2. Application Protocol (with ACs)

13. Proxying AC-Issuer 2. AC Request and Response AC-Verifier AC-Holder AC-Verifier 1. Application Protocol (no ACs) 3. Application Protocol (with ACs) Note: This is one model for proxying, others exist!

14. AC Delegation • X.509 model includes extensions supporting delegation and “chains” of Acs • Note: Not part of RFC 3281 • Delegation: Alice (AC Issuer1) says that Bob (AC Issuer2) says that Charlie (Owner) is an administrator • AC Chains provide a way to implement this • AC1=[Issuer: Alice, Owner: Bob; Extensions=“AC issuer”] • AC2=[Issuer: Bob, Owner: Charlie; Attributes: role=“administrator”] • Chain = AC1 + AC2 • If Dave (AC Verifier) “trusts” Alice, then he can tell that Charlie is an administrator without explicit configuration about Bob.

15. X.509 Delegation Concept

16. (Killer!) Issues with AC delegation • Practical: How does owner (Charlie) or verifier (Dave) find superior ACs? • Similar (but easier) issue for PKCs • Theoretical: Given a selection, how can Charlie know which AC chain is good for Dave? • Much worse than for PKCs – keys do “chain”, attributes don’t • Dave could expose his full set of ACLs, but that doesn’t seem wise • And doesn’t reference Bob in any case, so only serves to further confuse Charlie! • A Canadian DoD study (at 2002 NIST/Internet2 PKI Research Workshop) of procurement processes found that 109 certificates (both PKCs and ACs) were needed to buy a bar of soap!

17. ACs and Electronic Signatures • ETSI EESSI group defining ASN.1 (& near-XML:-) based data structures and ancilliary standards aimed at matching electronic signature legislation to digital signature mechanisms • Bascially an extension of S/MIME aka CMS SignedData aka PKCS#7 • Not explicitly supported by RFC3281 • Includes use of ACs (as does CMS!) • To indicate “authority” for electronic signature • E.g. “Alice (Issuer) says that Bob (Owner) is allowed to electronically sign for soap purchases” • Not clear if this approach will take off (maybe due to current lack of supporting s/w)

18. General Issues with X.509 ACs • Even RFC3281 has issues though • Current lack of support in protocols, toolkits and applications • But: • Authorisation mangagement is a real problem • More-so today with “web services” than previously • Web services really does involve multi-vendor application layer interoperability • And XML is the flavour of the month anyway!

19. A concrete problem for today • Two separate networks at two different companies • Each has own security and technology deployment • Companies form an on-line partnership

20. The Problem • Two separate networks at two different companies • Each has own security and technology deployment • Companies form an on-line partnership • Want on-line customers to be able to traverse each other’s Web sites with Single Sign-on ?

21. The Old Solution • The Two companies get their IT departments together • They share user information • They hack together a SSO solution • They may be forced to open up components of their network to their partners • Both companies spend too much time maintaining the solution

22. The Problem Made Worse • Along comes a third company • It wishes to join the two company alliance • Now all three companies must make changes • Maintaining the system across three networks is a nightmare • Then along comes company number four….

23. SAML: TNG Solution • Industry adopted standard way to provide SSO between separate networks • Companies only need to maintain their own data • Scalable to any number of partners • Allows companies to control which information is shared with its partners on a partner by partner basis • All cross company communications protected by strong cryptography

24. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? Browser

25. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? Browser 1. The user authenticates to Company A’s Web system and browses through the site

26. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? http://Visit Our Partner! Browser 2. User clicks on a link that takes her to Company B. The link is setup to automatically take the User to Company A’s SAML server.

27. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? From: Company A Ref: User X Browser 3. Company A’s SAML server redirects the user’s browser to Company B’s SAML server. Some site specific information is added to the redirect data for use by Company B’s SAML server.

28. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? What’s up with User X? Is Partner B allowed to get this info? Browser 4. Company B’s SAML uses the site specific information to communicate with Company A’s SAML server.

29. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? SAML Assertion Browser 5. Company A and B’s SAML servers authenticate each other. Then Company A passes to Company B, for this specific user, the information they have agreed to share with each other

30. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? User: X Auth: Password CustStatus: Gold … Drinks: Coffee Browser 5. Company A and B’s SAML servers authenticate each other. Then Company A passes to Company B, for this specific user, the information they have agreed to share with each other

31. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? Add: User X Browser 6. Company B’s SAML server updates the authorization system with the new user information received from Company A.

32. Company A Web Environment Company B Web Environment SAML Service SAML Service SAML: How Does It Work? Company A password auth accepted! Browser 7. User gets redirected to Company B’s Web system. Company B’s authorization system determines her access permissions.

33. SAML • The user is automatically redirected to Company B’s web site with no further action other than the initial click on the link • Company B now has the required user information so that it can make authorization checks • SAML exchanged data ages and gets thrown away so that it doesn’t linger

34. SAML Security Issues • All communications are over SSL • SAML servers authenticated each other before talking • SAML sites will only pass user information to the correct destination SAML server • Users are properly authenticated each step of the way even if they are not prompted • SAML assertions are identified by originating site • Replay attacks to get SAML information are prevented • Cached data in SAML servers has limited lifetime

35. SAML vs. X.509 ACs • Actually quite similar concepts • One with ASN.1, one with <AngleBrackets> (XER anyone!) • Any system architecture for one can work for the other given suitable fussing with details • Privacy issues: both the same, but perception will (probably) be that SAML is worse • Performance: again similar, though SAML may end up better

36. SAML • SAML maps better to current web services primitives • URIs/URLs and HTTP re-direct in particular • SAML maps better to legacy authentication schemes • Much better industry support today • Esp. amongst authorisation product vendors (including guess who?) • Associated developments: XACML, Liberty • Not necessarily a benefit to SAML though! (Complexity) • Overall security of multi-vendor SAML-based systems still needs to be seen to be demonstrated (for a while longer) in the wild • But, properly implemented and deployed, SAML is definitely better than what’s there now

37. Attribute Certificates • ACs map better to X.509 based PKI • When all is said and done PKI is the only real authentication infrastructure other than passwords or OS account mechansims • More military systems work has considered ACs (might well change) • Security considerations more mature and with fewer external dependencies • Lack of software the main problem

38. Conclusions • There’s a whole lot of well-defined infrastructure stuff • X.509 ACs and SAML are both real, usable technologies • SAML is definitely more fashionable and will clearly “win” if/when “web services” takes off • X.509 AC model however still provides lots of lessons that ought not be ignored • Format issues are not the main game in any case! • Populating the database of privileges is the real challenge • So dual-support or migrating back and forth is possible

39. Questions? Nice, easy ones preferred :-) Thank you!