Distributed Authorisation Infrastructures – X.509

Attribute Certificates and SAML

Stephen Farrellstephen.farrell@baltimore.ie

Authori[sz]ationOperating 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)

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)

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

In-play authorisation infrastructures

X.509: Attribute Certificates– RFC 3281, ETSI-EESSI

SAML: XML authorization framework– XACML, XrML, Liberty

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)

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…

AC fields

ACs are signed; To-be-Signed structure:– version– holder– issuer– signature– serialNumber– attrCertValidityPeriod– attributes– extensions

Other AC concepts

Holder linkageAudit identity extensionTargettingAttribute encryptionRevocationAA controls (for AC issuer’s PKC)

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

“Pull” Model

AC-Issuer

AC-VerifierAC-Holder

2. AC Requestand Response

1. Application Protocol (no ACs)

Actually could be “in front” of the real issuer

“Push” Model

AC-Issuer

AC-VerifierAC-Holder

1. AC Requestand Response

2. Application Protocol (with ACs)

Proxying

AC-Issuer

AC-VerifierAC-Holder

2. AC Requestand Response

3. Application Protocol (with ACs)

AC-Verifier1. 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.

X.509 Delegation Concept

Verifier

Source of authority

Claimantclaims

privilege

trustsunconditionally

delegatesprivilege

delegatesprivilege

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

General Issues with X.509 ACs

Even RFC3281 has issues though–Current lack of support in protocols, toolkits and

applicationsBut:

–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!

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 informationThey hack together a SSO solutionThey 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 partnersAllows 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 AWeb Environment

SAML Service

Company BWeb Environment

SAML Service

Browser

SAML: How Does It Work?

Company AWeb Environment

SAML Service

1. The user authenticates to Company A’s Web system and browses through the site

Company BWeb Environment

SAML Service

Browser

SAML: How Does It Work?

Company AWeb 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 BWeb Environment

SAML Service

Browser

http://Visit Our Partner!

SAML: How Does It Work?

Company AWeb Environment

SAML Service

Company BWeb 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 AWeb Environment

SAML Service

Company BWeb 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 AWeb Environment

SAML Service

Company BWeb Environment

SAML Service

Browser

SAMLAssertion

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 AWeb Environment

SAML Service

Company BWeb Environment

SAML Service

Browser

User: XAuth: 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 AWeb Environment

SAML Service

Company BWeb 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 AWeb Environment

SAML Service

Company BWeb 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 <AngleBrackets>

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

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

Thank you!Questions?

Nice, easy ones preferred :-)