Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Authentication


Notes and discussion about Authentication, Tickets, Credentials, Privileges, etc.

Notes and discussion about Authentication, Tickets, Credentials, Privileges, etc.

High-level Goals and Non-goals

  • It can be assumed that all entities we want to authenticate or delegate to have a GID
  • For the prototype, we may have a fixed, relatively small set of trust anchors (ie. federated facilities)
  • For the prototype, delegation may be unmediated, as long as our design presents a path to unmediated delegation
  • While there will be certificates, credentials, etc. "under the hood", most users will use a interface (ie. the Emulab interface) that manages these for them. We will, however, give users the tools to generate and manipulate these structures, as appropriate

Concrete Implementation Decisions

  • GIDs and authentication
    • Main GID Page
    • Old, obsolete: A GID will be the hash of a principal's public key.
    • The holder of a GID will also hold a certificate, traceable back to one of the trust roots, to be used for authentication
    • We will run a centralized name registry to map GIDs to accountability information (ie. real name and contact information), but it is not necessary to contact this registry to authenticate someone using a GID
    • The certificates used for GIDs will be standard, or slightly modified, x509 certificates
    • Calls to the GMC API will be wrapped in an authenticated SSL session - this means that authentication information is not passed to each API call
  • Separating privileges and credentials
    • A privileges is a bit of XML describing an action a principal, identified by a GID, can take
    • The set of privileges for the prototype will roughly correspond to the GMC API calls
    • A privilege includes at least two GIDs: The GID of the object (ie. CM) the credential is good for, and the GID it has been bound to
    • A credential is simply a priviledge signed by some authority (possibly, a chain of certificates going back to that authority)
    • We will use XML Digital Signatures to sign credentials. Specifically, the XMLSEC library.
    • The policies for delegating a priviledge (ie. can this user give it to someone else) will be encoded in the privilege itself (ie. not added by the certificate)
    • The set of delegation policies will be very simple for this prototype, beginning with a binary delegable/not delegable bit, and we will likely add a few more policies as we find a need for them

Important Email Exchanges

Note: Privileges were called 'capabilities' when we had this discussion

Other Notes