Authorisation Infrastructures X.509 Attribute Certificates and SAML

1
Authorisation Infrastructures X.509 Attribute
Certificates and SAML

• Stephen Farrell
• stephen.farrell_at_baltimore.ie

2
Authoriszation

• 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)
• Hasnt really worked well for
• Application layer authorization when that doesnt
  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)
• 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 distibuted ACLs
• ECMA/SESAME Privilege Attribute Certificates
• Corba Secure IIOP, DCE RPC and/or SESAME
• Win2k Similar to the above!

5
In-play authorisation infrastructures

• X.509 Attribute Certificates
• RFC 3281, ETSI-ESSSI
• SAML XML authorization framework
• XACML, XrML, Liberty

6
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

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

8
AC fields

• To-be-Signed structure
• version
• owner
• issuer
• signature
• serialNumber
• attrCertvalidityPeriod
• attributes
• extensions

9
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

10
Pull Model
AC-Issuer
Actually could be in front of the real issuer
2. AC Request and Response
AC-Verifier
AC-Owner
1. Application Protocol (no ACs)
11
Push Model
AC-Issuer
1. AC Request and Response
AC-Verifier
AC-Owner
2. Application Protocol (with ACs)
12
Proxying
AC-Issuer
2. AC Request and Response
AC-Verifier
AC-Verifier
AC-Owner
1. Application Protocol (no ACs)
3. Application Protocol (with ACs)
Note This is one model for proxying, others
exist!
13
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
• AC1Issuer Alice, Owner Bob ExtensionsAC
  issuer
• AC2Issuer Bob, Owner Charlie Attributes
  roleadministrator
• Chain AC1 AC2
• If Dave (AC Verifier) trusts Alice, then he can
  tell that Charlie is an administrator without
  explicit configuration about Bob.

14
X.509 Delegation Concept
15
(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 dont
• Dave could expose his full set of ACLs, but that
  doesnt seem wise
• And 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!

16
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 PKCS7
• 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)

17
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

18
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

19
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 others Web sites with Single Sign-on

?
20
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

21
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.

22
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

23
SAML How Does It Work?
Browser
24
SAML How Does It Work?
Browser
1. The user authenticates to Company As Web
system and browses through the site
25
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 As SAML server.
26
SAML How Does It Work?
From Company A Ref User X
Browser
3. 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.
27
SAML How Does It Work?
Whats up with User X?
Is Partner B allowed to get this info?
Browser
4. Company Bs SAML uses the site specific
information to communicate with Company As SAML
server.
28
SAML How Does It Work?
SAML Assertion
Browser
5. 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
29
SAML How Does It Work?
User X Auth Password CustStatus Gold Drinks
Coffee
Browser
5. 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
30
SAML How Does It Work?
Add User X
Browser
6. Company Bs SAML server updates the
authorization system with the new user
information received from Company A.
31
SAML How Does It Work?
Company A password auth accepted!
Browser
7. User gets redirected to Company Bs Web
system. Company Bs authorization system
determines her access permissions.
32
SAML

• The user is automatically redirected to Company
  Bs 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 doesnt linger

33
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

34
SAML vs. X.509 ACs

• Actually quite similar concepts
• One with ASN.1, one with ltAngleBracketsgt (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

35
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 whats there now

36
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

37
Conclusions

• Theres 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?

38
Thank you!

• Questions?
• Nice, easy ones preferred -)