Best practices dictate that individuals should speak as themselves: that is, the entity on
the other side of an SSL connection is the one referred to by the certificate on the
connection. Obviously, people typically use tools or software interfaces to create these
connections. When a tool is acting directly on a user’s desktop using the user’s key
and cert with the user’s explicit permission, it may be acceptable to consider the tool
as speaking as the user. But for many tools, the tool is acting on behalf of the user in
invoking Federation or AM API calls. In this case, it is important for the tool to not
speak as the user but to speak for the user, and to have the service to whom the tool is
speaking handle the authorization and accountability of this request accordingly.
Accordingly, a Federation Registry and associated Authorities should support speaks-for
API transactions. These API transactions use the same signatures as the calls described in
this document, with these enhancements:
- A 'speaking_for' option containing the URN of the user being spoken for
- A speaks-for credential in the list of credentials: a statement signed by the user
indicating that the tool has the right to speak for the user, possibly limited to a
particular scope (e.g. slice, project, API call, time window).
The service call is then required to determine if the call is being made in a speaks-for
context or not (that is, the ‘speaking_for’ option provided). If so, the call must
determine if the tool is allowed to speak for the user by checking for the presence of a
valid speaks-for credential and the spoken-for user’s cert. If so, the call should
validate if the user is authorized to take the proposed API action. If so, the action is
taken and accounted to the user, with identity of the speaking_for tool logged. If the
call is ‘speaks-for’ but any of these additional criteria are not met, the call should
fail with an authorization error. If the call is not a ‘speaks-for’, then the normal
authorization is performed based on the identity (certificate) provided with the SSL
connection.
Aggregates are also encouraged to support speaks-for authentication and authorization, but
this is an aggregate-internal policy and implementation decision, and outside the scope of
this document.
motine
commented
10 years ago
Documentation from the API: