Tuesday, January 3, 2012

UMA: Trust in a distributed authorization system

During the last UMA WG Webinar (slides) which was focused on multiple implementation demos and UMA's OpenID Connect relationship, I had the opportunity to explain the current UMA trust model. Here are some descriptive details about this model.
Many literatures try to define the concept of trust. According to the ITU-T X.509, Section 3.3.54, trust is defined as follows: “Generally an entity can be said to ‘trust’ a second entity when the first entity makes the assumption that the second entity will behave exactly as the first entity expects.”
UMA trust model is built on the following implications that are based on the UMA features:
  • Host's Authorization decision is externalized to the Authorization Manager (AM).
  • There is no relationship between a Requester and the Authorization manager prior to a request for access. 
Externalizing an authorization decision requires a formal registration process and consequently a delegation of protection of a resource.
Furthermore, because the AM does not know the requester directly, it has to use information from third parties who know the requester better. Normally, the AM trusts these third parties only for certain things and only to certain degrees.
These trust and delegation aspects make UMA's authorization system different from traditional access control.
The following diagram illustrates is an high level representation of the UMA Trust Model which describes the trust relationship. We use a multiple triangles representation because it's useful to represent this complex  trust relationship (2 parties + one authority).
In the diagram are represented the three main aspects of the trust model: Registration, Trusted Claims and Delegation of Authority respectively related to the UMA functional model which includes: Protect, Authorize and Access (that you can see in the centered triangle). 

The Registration aspect describes the Host-AM Trust Relationship, this includes technical procedures (such as private key exchange), legal agreements and policies.
On the left side, the vertex called "Accreditation system" represents a third party (e.g. Registration Authority) that we think could be involved to guarantee an adequate level of trustworthiness about the parties in case of a specific business (i.e. Healthcare, financial credit). It is not about identity exclusively.

The Trusted Claims aspect describes the AM-Requester Trust Relationship. For this specific aspect we leverage OpenID Connect specification and its levels of assurance to enable an Claim-based authorization system (see slideshare here). The SmartAM demo in the webinar showed a case of OpenID Connect-sourced trusted claims.

Last is the Delegation of Authority aspect which describes the Host-Requester Trust relationship, which is based on a delegation process, specific of the UMA protocol sequence which enables the propagation of trust.
Examples of delegation are:
  • The Authorizing User delegates rights of protecting its resource to the Authorization Manager.
  • The Host delegates rights of authorizing decision to the Authorization Manager. 
  • The Authorization Manager delegates rights of the Requester’s proof-of claims’s to a 3rd party Claims Provider.
For more details about the expectations and responsibilities of various parties interoperating in the User-Managed Access (UMA) context, please take a look at UMA Trust Model document and the approach for Measuring Element of Trust.
See also UMA Trust and Security Implication FAQ