Outline

1
Outline

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

2
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

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

4
Then...
5
Now...
6
Soon...
7
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  

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

9
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

10
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

11
AM Relationships
 
 
   
12
Athens what the UK has now

• Username and password for every user
• (in a single, but replicated, national database)
• User administration partly devolved to HEIs
• Developing a devolved authentication model
  (AthensDA)
• 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
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

19
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.)

20
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

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

22
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

23
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

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

25
The Solutions

• AthensDA authenticating at institution and
  using attributes.
• A-Select a central place to route all
  authentication requests.
• Liberty Alliance federate access (linked
  accounts across Identity Providers and Service
  Providers).
• Shibboleth WAYF and use of attributes.
• SSO.net simple PKI infrastructure.

26
AthensDA Methodology

• The user authenticates with his or her home
  institution via a login page.
• The institution passes permissions (rights
  groups) for the user to Athens.
• Athens uses the permissions passed by the
  institution to authorise access to resources,
  rather than requesting an additional
  authentication.
•  

27
AthensDA Issues

• Athens is essentially a service that acts on
  behalf of a range of Service Providers to provide
  users with a single set of credentials for all of
  the services represented. It does not cover all
  the services a user may wish to use, neither does
  it typically provide access management for
  locally held information (although some
  institutions have utilised Athens authentication
  in-house through private consultation with
  Athens).
• The Athens credentials assigned to a user are
  tied to a specific institution the permission
  sets defined by the institution are based on the
  services that the institution subscribes to, and
  the user rights to access these are revoked when
  the user completes study or leaves the
  institution. The current framework revokes both
  authentication details and permission sets in the
  same operation.
• AthensDA would be a sensible framework to pursue
  inline with a centralised, national approach to
  lifelong learning and access to student
  transcripts. It has few discernable benefits for
  consortia.

28
A-Select Methodology

• A-Select provides a central point for users to
  authenticate to applications.
• All authentication requests received by an
  application are sent to the central A-Select
  server, which then communicates with potential
  authentication service providers through the
  users browser.
• Once the A-Select server is satisfied that
  authentication has been completed, it issues the
  user with a ticket granting ticket.
• The user is then redirected to the application
  they wish to use, where he or she uses the
  ticket granting ticket to receive an
  application ticket that will allow access to
  the application.

29
A-Select Issues

• 1. Although A-Select recognises a
  cross-institutional model, its concern is with
  permitting access to applications held at a
  certain institution to external users (from known
  institutions). In a lifelong learning context,
  this would be useful for institutions that wished
  to open up learning environments to external
  students (both online and physical) but did not
  want to violate access agreements. It would also
  be a useful tool for institutions to prove an
  external students identity without having to
  hold details locally.
•  
• 2. A-Select has currently only implemented a
  small number of (potentially irrelevant)
  authentication service providers.

30
A-Select Issues

• 3. The A-Select server databases offer potential
  use to lifelong learning consortia in the form of
  attribute stores.
•  
• 4. A-Select recognises that a user may have
  several different authentication sets, but
  focuses on the type of authentication required by
  the application (i.e. minimum level of
  authentication). This information is stored in
  the A-Select server in the form of application
  attributes. (There may be potential for this to
  be manipulated to suit the purposes of lifelong
  learning consortia).

31
Liberty Alliance Methodology

• The user arrives at a Service Providers website
  with no authentication evidence.
• The Service Provider presents the user with a
  welcome page, including a list of Identity
  Providers from which the user can chose.
• The user selects an Identity Provider, and is
  asked to authenticate either via
• a redirection to the Identity Provider website
  (which returns the user to the Service Provider
  website once authentication has been accepted).
• an Identity Provider dialog box invoked from the
  Service Provider page.
• an embedded form within the service Provider web
  page.
• Once the authentication process has been
  accepted, the user is able to access all services
  at the Service Provider that he or she initially
  visited, and move between the services provided
  across the circle of trust without having to
  re-authenticate.

32
Liberty Alliance Issues

• The Liberty Alliance specification is designed to
  support the needs of business transactions on the
  web (federate accounting).
• The framework has strong advantages for the user,
  as it would not require any additional work on
  his or her behalf to set up. The specification
  does, however, require the user to federate the
  link between Providers.
• Concepts of Identity Federation used by LA may
  support the projects desire to federate identity
  across the lifelong learning experience. The
  projects will be mostly interested in the ability
  to federate several different Identity Providers.
  Unfortunately, this concept is not as well
  defined by the specification as the need to
  federate between Service Providers.

33
Liberty Alliance Issues

• Although LA recognises that a user may have
  multiple accounts, which they wish to relate, its
  aims in relating the accounts are very different
  from lifelong learning aims. LA assumes that the
  user will have existing and ongoing relationships
  with all the providers (both identity and
  service) within the circle of trust. This may be
  useful for consortia that have students actively
  pursuing courses at more than one institution.
  This would also be useful for consortia that plan
  to offer different services to students, or to
  control the overall access management at each
  institution.
• LA is concerned with federation between several
  separate services. The lifelong learning
  projects are more focused on providing one
  service, but federating these services because
  the Identity Provider has changed.
• The reciprocal honouring of identities to allow
  single sign-on may have some attractions for the
  SHELL project, and its desire to allow users to
  log-in with any ID assigned to them.

34
Shibboleth Methodology

• User attempts to access a shibbolized service.
• Resource provider needs attributes about the
  user. Uses its SHIRE and WAYF service.
• The WAYF service communicates with a handle
  service at an institution.
• The handle service interacts with user,
  establishes authentication and then passes a user
  handle to the SHIRE.
• The SHIRE passes information to the SHAR, which
  can then communicate with the institutional AA to
  gain attributes for the user.
• The attributes (group access rights) are then
  used to make an access management decision.

35
Shibboleth Issues

• Potential model for lifelong learning in the
  recognition of multiple AA. However, only one AA
  can be used at one time for a user.
• The WAYF service offers potentially useful
  functionality.
• The use of a separate user handle may address
  multiple identifier issues.
• Shibboleth is very much still in development.
• There is a specific interest in the system from
  JISC (perhaps more specifically in the use of
  SAML).
• Offer standards-based solution.

36
SSO.net Methodology

• When the user attempts to enter a service, the
  provider sends an encrypted message to sign.
• This prompts the users plug-in to ask the user
  to authenticate (username and password).
• The plug-in uses the password to create the
  users half of the private key.
• The private key is then authenticated and the
  plug-in uses this to create a secure channel with
  the Secure Identity Appliance.
• The Secure Identity Appliance then verifies the
  user with its half of the private key and the
  public key. It creates a secure channel with
  the user and issues a session ticket.
• The plug-in then sends the Secure Identity
  Appliance the encrypted message from the service
  provider.
• The appliance completes its half of the
  signature and passes back to the plug-in.
• The plug-in completes the users half of the
  signature and sends to the service provider.

37
SSO.net Issues

• PKI is perhaps most sensibly addressed at an
  institutional (or indeed national) level. PKI
  certainly has a role within lifelong learning,
  potentially allowing a student to carry a
  personal private key from institution to
  institution for authentication purposes. Its
  scale and role within the consortia projects
  would need to be carefully considered.
•  
• The way that keys are carried, accessed or
  recalled by users is important in lifelong
  learning, where sustainability is highly
  important. Singlesignon.net achieves this
  through the use of a username and password.
•  

38
SSO.net Issues

• The model offered by singlesignon.net assumes a
  central Secure Identity Appliance, even though it
  recognises that users may have different accounts
  (profiles) with different providers. The
  splitting of the private key between the user and
  Secure Identity Appliance enhances security but
  restricts the use of the private key for the
  user.
• The Identity Vault facility may offer some
  attraction to the projects for storing learner
  record information. This enables one central
  institution (Secure Identity Appliance holder) to
  set up a vault of personal information for the
  user, but restrict access to fields to different
  organisations. The SIA can even restrict access
  to the holding institution.

39
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