Changes between Version 8 and Version 9 of TIEDABACDemo

07/10/09 17:42:02 (13 years ago)




    v8 v9  
     73During the negotiation, the GPO controller will need to get access to material to confirm ISI's signature on its credential, but it can presumably get that information from the NSF.  The GPO controller knows NSF well enough to delegate authority to it, so it presmably has keying information for the NSF.  If the keying information is public, Ted can pass along ISI's identifier/key as well.
     75The basic protocol action is to present the other side with part of a graph and reply by extending the graph as much as possible toward the goal.  How that exchange pans out depends considerably on what the participants know beforehand and the access control policies they place on their credentials.
     77In an open environment, the GPO may publish its credential broadly.  This means that requesters can start with enough information in their possession to create the entire authorization graph and include it in their request, reducing the number of exchanges.  Conversely, a tight lipped requester may only disclose its NSF funding status to an requester that has some NSF credential.  Such a requester would reply to the initial request with nodes indicating that the controller needs to prove a subordinate credential to the requester.  On receipt of that proof, the requester would sahre the NSF.funding credential.  Such an exchange continues as long as either side is able and willing to extend a graph and the initial request path has not been established.
     79This simple operation - building graphs collaboratively from validated credentials - can result in a broad range of negotiation strategies.  It can be used to facilitate disconnected operation (by bounding the necessary interactions) or to maintain control over sensitive information.
     81== Rich Auditing Information ==
     83The graphs generated by the authorization negotiation also act as detailed logs of what was allowed and why.  A log entry containing the credentials and identifiers/keys used to validate them provides the complete set of information that led to the access control decision.  Such logging is of significant use in assessing intrusions or demonstrating that an entity has adhered to a resource control policy.  Such adherence may be important if a resource control policy is mandated by a funder or other contract.
     85== Authentication and entering the ABAC system ==
     87A key aspect of ABAC's power is that its reasoning system makes few demands on the systems used to establish principals in the system. 
     88Principals need to have three properties:
     90 * An entity claiming to be a given principal can prove it interactively
     91 * Two entities referring to the same principal must be sure that they are referring to the same entity
     92 * A principal must be able to sign assertions
     94Any authentication system that establishes a public key meets these requirements, modulo a system to map various key types into a single identifier, e.g. hashing the bits of the keys in a common format.  PGP keys and X.509 certificates directly meet those requirements (even self-signed X.509 certificates will do).  Systems that attest user attributes, like [ Shibboleth ] can attest a public key/principal as an attribute.  Such systems have the added utility that they can act as external credential stores as well.
     96Some principals never attest attributes, e.g., end users.  Such users that are only identifiable by something like an InCommon [ eduPersonPrincipalName] or kerberos name can be converted to the same principal identifier space by hashing the name along with the namespace (Kerberos,InCommon, etc.) into the same hash space as the public-key based systems.  Some care must be taken with functions and hashspace sizes, but collisions can be made arbitrarily unlikely.
     98When possible binding to a public-key-based identifier is infinitely preferred.