| | 1 | = Architecture = |
| | 2 | |
| | 3 | Our model of authorization in the DFA is that principals are granted the right to perform operations on other principals bases on attributes of the principals. Possession of a given attribute by the requesting principal allows the requested operation to proceeed. The attribute required is set by the principal being operated on. |
| | 4 | |
| | 5 | == Principals == |
| | 6 | |
| | 7 | Principals are the players in the authorization system. They have a unqiue identity in the system (though a single real world entity may act as several principals in the system), can prove that identity and can make assertions about attributes. Principals in the DFA are identified by their [FeddAbout#GlobalIdentifiers:Fedids fedid]. Within the authorization framework, fedids can be used to sign create credentials as well. |
| | 8 | |
| | 9 | Principals cause actions in the system by requesting operations on other principals. The two principals communicate in such a way that they are certain of one another's identity, and negotiate the access by reasoning about the attributes of the requester. The simplest way to do this is a mutually authenticated interactive connection, but other store and forward sorts of operation are also possible, as long as the two can authenticate the operation request and carry out a negotiation. |
| | 10 | |
| | 11 | Authentication is a binding of a request to a requesting principal about which the object principal can then reason. Many forms of authentication are possible here, and we intend to support as many as possible. The goal of authentication is to bind the request to a principal (i.e., their [FeddAbout#GlobalIdentifiers:Fedids fedid]). |
| | 12 | |
| | 13 | == Attributes and Credentials == |
| | 14 | |
| | 15 | Attributes are asserted about a principal by a principal. Each principal defines its own namespace of attributes, though for principals to agree on how to reason using them they must agree on the semantics of the relevant subset of each others attributes. We generally use a dotted notation of the form `Principal.attribute` to represent an attribute. Attributes are free-form strings (without dots) that are chosen to have some meaning. The principal is the [FeddAbout#GlobalIdentifiers:Fedids fedid] of the principal in question, though in these examples we will replace it with a string representing the principal's role in the discussion. One could imagine a principal representing the DETER testbed defining an attribute `user` that means that any principal about which that is asserted is a user of the testbed. Such an attribute would be referred to as `DETER.user` where `DETER` is a shorthand for the testbed's fedid. |
| | 16 | |
| | 17 | Binding an attribute directly to a principal is done by issuing an assertion signed by the principal whose namespace the attribute is in; such an assertion is called a ''credential''. The simplest credentials are direct bindings of attributes to principals, and are statements digitally signed using a key bound to the fedid. The X.509 attribute certificate is suitable for implementing a credential. |
| | 18 | |
| | 19 | Credentials also represent delegations, as described [http://groups.geni.net/geni/wiki/TIEDABACModel elsewhere]. These delegations are also straightforward encodings of these assertions, signed by the principal controlling the namespace of the deduced attribute. If the DETER principal asserts that all Emulab users are DETER users, that credential is signed by the DETER principal. |
| | 20 | |
| | 21 | While a delegation credential usually represents some kind of agreement or mutual understanding between principals, the creation of the credential needs only the signer's input. When the DETER testbed creates a credential that asserts that all `EMULAB.user`s are `DETER.users`, that credenital can be created without the knowledge of the EMULAB principal, and does not depend on the existence of even one user with the `EMULAB.user` attribute. |
| | 22 | |
| | 23 | Credentials may be issued with lifetimes. Once a credential expires, it is no longer valid and can no longer be used to reason about authorization decisions. |
| | 24 | |
| | 25 | Once a credential is created, it is valid fairly independent of the generating principal. (It is fairly independent only because validating the signature on the credential requires getting sufficient information to validate the signature, which may involve contacting the signer, though in need not.) They are generally passed to those principals that can make use of them, and may even be published. |
| | 26 | |
| | 27 | It is worth noting that some credentials embody information about a principal or the policies of a principal that are not generally known, nor are they intended to be. The ABAC authorization model has provisions for controlling how principals release credentials to others, including securely establishing preconditions on that release. This fact constrains both the number of parties to a negotiation and the system used to find credentials. |
