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
- Leigh's email message from March 26, 2008 1:47:42
- Rob and Leigh's email exchange from Mar 12, 2008 17:59:46
Other Notes
- ShibbolethAndSAMLNotes
- Leigh's notes about Rob/Leigh phone discussion on Mar 29th, 2008
- Leigh's notes from meeting on Apr 22nd, 2008