Presentation on theme: "Authorisation Infrastructures – X.509 Attribute Certificates and SAML Stephen Farrell"— Presentation transcript:
Authorisation Infrastructures – X.509 Attribute Certificates and SAML Stephen Farrell email@example.com
Authori[sz]ation History tells us that 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 authorization when that doesn’t map nicely to OS entities –Distributed Systems –Despite some valiant attempts (e.g DCE, Corba)
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) 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)
Who tried what? Military: Bell-LaPadula, MLS, various others DCE: Authentication and distibuted ACLs ECMA/SESAME: Privilege Attribute Certificates Corba: Secure IIOP, DCE RPC and/or SESAME Win2k: Similar to the above!
In-play authorisation infrastructures X.509: Attribute Certificates –RFC 3281, ETSI-ESSSI SAML: XML authorization framework –XACML, XrML, Liberty
X.509 Originally part of X.500 (Directory) set of 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 –Main PKC profiles RFCs 3279, 3280 and AC profile is RFC 3281
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 an “owner” 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
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) associated attributes with owner and makes an access decision
“Pull” Model AC-Issuer AC-VerifierAC-Owner 2. AC Request and Response 1. Application Protocol (no ACs) Actually could be “in front” of the real issuer
“Push” Model AC-Issuer AC-VerifierAC-Owner 1. AC Request and Response 2. Application Protocol (with ACs)
Proxying AC-Issuer AC-VerifierAC-Owner 2. AC Request and Response 3. Application Protocol (with ACs) AC-Verifier 1. Application Protocol (no ACs) Note: This is one model for proxying, others exist!
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.
(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!
ACs and Electronic Signatures ETSI ESSSI 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)
General Issues with X.509 ACs Even RFC3281 has issues though Current lack of support in protocols, toolkits and applications XML is the flavour of the month anyway! 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
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
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 ?
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
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….
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
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser
SAML: How Does It Work? Company A Web Environment SAML Service 1. The user authenticates to Company A’s Web system and browses through the site Company B Web Environment SAML Service Browser
SAML: How Does It Work? Company A Web Environment SAML Service 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. Company B Web Environment SAML Service Browser http://Visit Our Partner!
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser From: Company A Ref: User X 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.
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser 4. Company B’s SAML uses the site specific information to communicate with Company A’s SAML server. What’s up with User X? Is Partner B allowed to get this info?
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser SAML Assertion 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
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser User: X Auth: Password CustStatus: Gold … Drinks: Coffee 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
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service Browser 6. Company B’s SAML server updates the authorization system with the new user information received from Company A. Add: User X
SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Service 7. User gets redirected to Company B’s Web system. Company B’s authorization system determines her access permissions. Browser Company A password auth accepted!
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
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
SAML vs. X.509 ACs Actually quite similar concepts –One with ASN.1, one with (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
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) in the wild –Properly implemented and deployed, SAML is definitely better than what’s there now
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
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 –Do you like headaches?