Authorisation Infrastructures X.509 Attribute Certificates and SAMLStephen Farrellstephen.farrell@baltimore.ie

Authori[sz]ationHistory tells us that Operating Systems tend to have more-or-less consistent authorization modelsMultics, Unix, WindowsAll offer an authorization infrastructure (as do mainstream DBMSs)Hasnt really worked well for Application layer authorization when that doesnt map nicely to OS entitiesDistributed SystemsDespite some valiant attempts (e.g DCE, Corba)

Why this lack of infrastructure?If we think in terms of subjects, objects and permissionsThe subjects may not map well to OS accountsThe 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 SESAMEWin2k: Similar to the above!

In-play authorisation infrastructuresX.509: Attribute CertificatesRFC 3281, ETSI-ESSSISAML: XML authorization frameworkXACML, XrML, Liberty

X.509Originally part of X.500 (Directory) set of standardsDefines Public Key Certificate (PKC) and Attribute Certificate (AC) data structures and semanticsDoes not define supporting protocolsIn 1995 an IETF working group (PKIX) was chartered to profile X.509 and to define supporting protocolsMain PKC profiles RFCs 3279, 3280 and AC profile is RFC 3281

X.509 Attribute CertificatesMainline description is based on RFC3281Exceptions as noted Basic idea is to have an AC issuer who encodes privileges and other attributes of an owner into an attribute certificateLooks almost the same as an X.509 PKC but with attributes instead of a public keyWell defined attributes include: Authentication Information, Identities (Access, Charging), Role, Group, Clearance

AC fieldsTo-be-Signed structure:versionownerissuersignatureserialNumberattrCertvalidityPeriodattributesextensions

AC Usage for access controlShort-lived ACs are not unusual (minimum 1 second)Entities involved: AC Issuer, AC Owner, AC verifierVerifier trusts Issuer to only issue good ACs Owner provides evidence (e.g. digital signature) of ownershipVerifier checks AC and (all being well) associated attributes with owner and makes an access decision

Pull ModelAC-IssuerAC-VerifierAC-Owner2. AC Requestand Response1. Application Protocol (no ACs)Actually could be in front of the real issuer

Push ModelAC-IssuerAC-VerifierAC-Owner1. AC Requestand Response2. Application Protocol (with ACs)

ProxyingAC-IssuerAC-VerifierAC-Owner2. AC Requestand Response3. Application Protocol (with ACs)AC-Verifier1. Application Protocol (no ACs)Note: This is one model for proxying, others exist!

AC DelegationX.509 model includes extensions supporting delegation and chains of AcsNote: Not part of RFC 3281 Delegation: Alice (AC Issuer1) says that Bob (AC Issuer2) says that Charlie (Owner) is an administratorAC 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 + AC2If Dave (AC Verifier) trusts Alice, then he can tell that Charlie is an administrator without explicit configuration about Bob.

X.509 Delegation Concept

(Killer!) Issues with AC delegationPractical: How does owner (Charlie) or verifier (Dave) find superior ACs?Similar (but easier) issue for PKCsTheoretical: Given a selection, how can Charlie know which AC chain is good for Dave?Much worse than for PKCs keys do chain, attributes dontDave could expose his full set of ACLs, but that doesnt seem wiseAnd doesnt 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 SignaturesETSI ESSSI group defining ASN.1 (& near-XML:-) based data structures and ancilliary standards aimed at matching electronic signature legislation to digital signature mechanismsBascially an extension of S/MIME aka CMS SignedData aka PKCS#7Not explicitly supported by RFC3281Includes use of ACs (as does CMS!)To indicate authority for electronic signatureE.g. Alice (Issuer) says that Bob (Owner) is allowed to electronically sign for soap purchasesNot 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 thoughCurrent lack of support in protocols, toolkits and applicationsXML is the flavour of the month anyway!But: Authorisation mangagement is a real problemMore-so today with web services than previouslyWeb services really does involve multi-vendor application layer interoperability

A concrete problem for todayTwo separate networks at two different companiesEach has own security and technology deploymentCompanies form an on-line partnership

The ProblemTwo separate networks at two different companiesEach has own security and technology deploymentCompanies form an on-line partnershipWant on-line customers to be able to traverse each others Web sites with Single Sign-on?

The Old SolutionThe Two companies get their IT departments togetherThey share user informationThey hack together a SSO solutionThey may be forced to open up components of their network to their partnersBoth companies spend too much time maintaining the solution

The Problem Made WorseAlong comes a third companyIt wishes to join the two company allianceNow all three companies must make changesMaintaining the system across three networks is a nightmareThen along comes company number four.

SAML: TNG SolutionIndustry adopted standard way to provide SSO between separate networksCompanies only need to maintain their own dataScalable to any number of partnersAllows companies to control which information is shared with its partners on a partner by partner basisAll cross company communications protected by strong cryptography

SAML: How Does It Work?Browser

SAML: How Does It Work?1. The user authenticates to Company As Web system and browses through the siteBrowser

SAML: How Does It Work?2. User clicks on a link that takes her to Company B. The link is setup to automatically take the User to Company As SAML server.Browserhttp://Visit Our Partner!

SAML: How Does It Work?BrowserFrom: Company ARef: User X3. Company As SAML server redirects the users browser to Company Bs SAML server. Some site specific information is added to the redirect data for use by Company Bs SAML server.

SAML: How Does It Work?Browser4. Company Bs SAML uses the site specific information to communicate with Company As SAML server. Whats up with User X?Is Partner B allowed to get this info?

SAML: How Does It Work?BrowserSAMLAssertion5. Company A and Bs 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?BrowserUser: XAuth: PasswordCustStatus: GoldDrinks: Coffee5. Company A and Bs 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?Browser6. Company Bs SAML server updates the authorization system with the new user information received from Company A. Add:User X

SAML: How Does It Work?7. User gets redirected to Company Bs Web system. Company Bs authorization system determines her access permissions. BrowserCompany A password auth accepted!

SAMLThe user is automatically redirected to Company Bs web site with no further action other than the initial click on the linkCompany B now has the required user information so that it can make authorization checksSAML exchanged data ages and gets thrown away so that it doesnt linger

SAML Security IssuesAll communications are over SSLSAML servers authenticated each other before talkingSAML sites will only pass user information to the correct destination SAML serverUsers are properly authenticated each step of the way even if they are not promptedSAML assertions are identified by originating siteReplay attacks to get SAML information are preventedCached data in SAML servers has limited lifetime

SAML vs. X.509 ACsActually quite similar conceptsOne with ASN.1, one with (XER anyone!)Any system architecture for one can work for the other given suitable fussing with detailsPrivacy 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 particularSAML maps better to legacy authentication schemesMuch better industry support todayEsp. amongst authorisation product vendors (including guess who?)Associated developments: XACML, LibertyNot 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 wildProperly implemented and deployed, SAML is definitely better than whats there now

Attribute CertificatesACs map better to X.509 based PKIWhen all is said and done PKI is the only real authentication infrastructure other than passwords or OS account mechansimsMore military systems work has considered ACs (might well change)Security considerations more mature and with fewer external dependenciesLack of software the main problem

ConclusionsTheres a whole lot of well-defined infrastructure stuffX.509 ACs and SAML are both real, usable technologiesSAML is definitely more fashionable and will clearly win if/when web services takes offX.509 AC model however still provides lots of lessons that ought not be ignoredFormat issues are not the main game in any case!Populating the database of privileges is the real challengeSo dual-support or migrating back and forth is possibleDo you like headaches?

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