Trust Me I'm a Stranger

1
Trust Me - I'm a Stranger

• Access Management for Higher Education in the
  Widening World of the Web

John Paschoud, LSE Library, ANGEL Project Manager
with grateful acknowledgement to Alan Robiette,
JISC Programme Director for Authentication and
Securityltagr_at_westgate.force9.co.ukgt
2
Outline

• The problem
• Application scenarios
• Access Management
• Authentication
• Authorisation
• Authentication some solutions
• Authorisation mostly still problems
• Current developments

3
The problem Resources will become more hybrid

• Holdings --gt Access
• Print --gt Online Text --gt other media
• More essential resources will only be (affordable
  / available) in non-print form
• Convergence of
• open-ended library resources
• and directed learning resources

4
The problem Users will expect more access

• in terms of
• Where --gt Anywhere!
• When --gt 24/7!
• The variety of users (and their rights of access)
  will get greater
• and so will their expectations!

5
Then...
6
Now...
7
Soon...
8
The problem Implications for access management

• Traditional approaches are per system or even per
  application
• (also do not typically separate authentication
  from authorisation)
• These scale very poorly in large distributed
  environments
• Other concerns in large distributed systems are
• security
• privacy  

9
Application scenarios

• Controlled access to electronic information
• e.g. commercial materials in digital libraries
• Federated access to pedagogic materials
• e.g. to students of more than one institution
• Collaborative activities among widely distributed
  groups of people
• (the Grid being a particular case of this)

10
Access Management processes

• Registration establishing real-world identity,
  and binding that to one or more electronic
  identifiers
• Authentication establishing who or what is at
  the other end of the connection
• Authorisation establishing what that entity is
  permitted to do

11
Access Management business processes in HE

• Users (students, staff, etc) have contracts with
  an HEI
• (so only the HEI can do Registration)
• An HEI has contracts with partners, resource
  hosts, etc
• (for use by all or some classes of HEI
  members/users)
• Authentication and Authorisation are up for
  grabs

12
Athens what we have now

• Username and password for every user
• (in a single, but replicated, national database)
• User administration partly devolved to HEIs
• Combines authentication with authorisation to use
  resources
• Requires adoption (proprietary technology) by
  resource supplier

13
Approaches to Authentication

• Usernames and passwords
• Scale very poorly, not very secure unless
  precautions are taken to avoid clear-text
  transmission
• Kerberos
• Good solution for a single security domain,
  scales poorly across domains
• Digital certificates
• Not ideal but the most scalable solution we have

14
What is a digital certificate?

• The commonest identity certificates conform to a
  standard known as X.509
• Essentially an X.509 certificate is
• the public key of a public-private key pair
• bound to identifying information about its owner
• with an explicitly specified validity period
• digitally signed by a named issuing authority
  (referred to as a Certificate Authority or CA)

15
Using certificates in authentication

• User presents a public-key certificate to the
  service requiring authentication
• Service issues a challenge (random sequence)
• User signs this with private key and returns it
• Successful verification of the signature using
  the public key confirms the authentication

16
Advantages of certificates

• The authentication process is strong (no password
  or replayable sequence passes across the network)
• The public key certificate is protected from
  tampering by being itself digitally signed (this
  amounts to trusting the issuer)
• Potentially a universal credential

17
Weaknesses of certificates

• The only real weakness in the mechanism is the
  need to protect the private key
• If the private key is lost, the electronic
  identity becomes useless
• If the private key is stolen, the identity is
  fatally compromised
• High security systems often encode the private
  key in hardware (e.g. smart card)

18
Options

• Technical details of X.509 slide 19
• Political getting a CA organised for UK-HE
  slide 22

19
Specific drawbacks of X.509

• Naming and namespaces
• By default uses X.500 naming CNJohn Doe, CGB
  etc
• No global naming authority for X.500 names
• Thus namespace control is dependent on the CA
• Complex standard although quite widely
  implemented, there are many anomalies in
  individual implementations
• Revocation mechanisms are very primitive

20
Deployment of X.509

• Standard authentication mechanism for web
• Supported by all modern commercial browsers and
  most servers
• Also a widely available option for secure logins,
  virtual private networking etc.
• The only authentication mechanism for Grid
  middleware (Globus, Legion etc.)

21
X.509 and trust models

• Certificate contents may typically contain
• The issuers name (name of the CA)
• The subjects name (or other, e.g. pseudonymous,
  ID)
• The subjects organisation (e.g. university)
• Optionally a sub-unit field (e.g. department)
• Optionally a status attribute (e.g. Research
  staff)
• The service could readily make an authorisation
  decision based on any of these

22
Responsibilities of a CA

• Essentially, the CA is being trusted (directly or
  indirectly) to vouch for the unknown user
• CAs must document their policies and procedures,
  e.g. set out in detail
• How identification of real world identities is
  done
• The certificate issuing procedures and the
  processes for subsequent operations throughout
  their life cycle
• Examples include reissue, revocation, archiving
• Contractual liabilities, indemnities, etc.

23
Models for UK-HE certificate use

• Individual HEIs purchase user certs from a
  commercial CA
• (probably too expensive!)
• JISC runs (or contracts-out) a CA service issues
  user certs on request by HEIs
• (closest to existing Athens national service
  model)
• JISC certifies authenticity of each user
• JISC acts as head CA, HEIs may choose to act as
  sub CAs
• (HEI issues user certs directly)
• HEI certifies authenticity of user
• JISC certifies authenticity of the issuing HEI

24
Finer-grained authorisation

• A more interesting and less well studied problem!
• Few standards, though some are now emerging
• An area of current activity in many different
  communities

25
Problem definition

• Service provider sets business rules for access
  to a resource
• User typically has various characteristics which
  somehow determine his/her entitlements for
  resource access
• A policy language is required to map user data to
  access rules
• (and standard definitions, e.g. HE roles)

26
Earlier and on-going research

• Rivest, Lampson, Ellison (SDSI/SPKI)
• Gladney (IBM Almaden trust models)
• Herzberg et al (IBM Israel trust establishment)
• Sloman, Lupu et al (role-based access control)
• Bacon, Moody et al (roles/events)
• Chadwick (Salford X.509 applications)

27
Significant practical projects

• Shibboleth (Internet2)
• PAPI (RedIRIS, Spain)
• CAS (community authorisation server
  Globus/Grid)
• Permis (EU project Barcelona/Bologna/Salford)
• ANGEL

28
Permis - some details

• Makes use of X.509 attribute certificates
• These bind attributes to a public key
• May have a source of authority for the attribute
  separate from that which certifies the public key
  itself
• A feature of Permis is to allow multiple
  attribute authorities
• Permis has its own policy language, defined as an
  XML DTD

29
Shibboleth

• Designed for the higher education environment and
  to address multiple scenarios
• Essentially a protocol and rules for requesting
  and supplying attributes
• Messages between entities encoded in SAML
  (security attribute mark-up language)
• Strong emphasis on user privacy

30
Shibboleth message flow

• User approaches service provider (identifying
  home institution)
• Service provider requests attributes from users
  home institution
• Attribute release is conditional on institutional
  policy and user preferences
• Authorisation based on attributes received

31
Status of Shibboleth

• Design effort largely by working group of
  Internet2
• Coding by IBM, Carnegie Mellon, Ohio State
• First (alpha) code releases just appearing
• Production code due Summer 2002
• Significant interest from publishers etc.

32
Conclusions

• Authentication largely a solved problem
• Although we could do with some further
  improvements in the browser implementations
• Simple authorisation easy to do if certificate
  contents will suffice
• Finer-grained authorisation still a research
  problem but good solutions are not far off

33
Whats happening right now?

• Athens / EduServe announcement of Rome
• http//www.athensams.net/development/athens-rome-n
  ov2000/
• Future of Authentication for JISC Services
  consultation
• http//www.jisc.ac.uk/pub02/ar1/future_auth.html
• Middleware for the JISC Information Environment
• http//www.jisc.ac.uk/pub02/ar1/mware_disc.html
• LSE / EDINA pilot of Shibboleth
• http//www.angel.ac.uk