...
The initial goal here will be to define a spanning set of atomic functions (technology and protocol-agnostic to the degree possible) that can be shown to be combinable composable in different ways to compose construct commonly discussed multi-capability service and application models. The services and applications are the typical units of analysis when a given model is being presented.
The following is offered as an introductory example. Imagine that a university offers students a tab in its portal service with which to manage their white-pages entry in the online campus directory. Let's say that students should be allowed to control The service allows the student to specify which elements of their his/her white pages information should be viewable by anyone and which should be viewable only by faculty, staff and students at institutions within a specified set.
Atomic Table of atomic functionality required to implement such a management tool and the associated online white pages and their realization under two different models:
| Name | Relevant actor or component in SAML federation model | Relevant actor or component in UMA model | ||
|---|---|---|---|---|
| Request Authentication | End User A | Claim Identity | Person A as end user | Person A as Resource Owner |
| AuthenticateVerify Claimed Identity | Authentication Service fronting SAML IdP | Authentication Service fronting Resource Server | ||
| Request Authorization to edit White Page (WP) Information | End User Person A as end user | Person A as Requesting Party A | ||
| Grant Authorization to edit WP Information | Portal Tab App behind SAML SP | Authorization Server | ||
| Edit WP Information | End User Person A as end user | Person A as Resource Owner | ||
| Set Access Policy for WP Information | End User Person A as end user | Person A as Resource Owner | ||
| Persist Access Policy for WP Information | Not SAML Specified | Authorization Server | ||
| Put WP Information Online | Portal Tab | Resource Server | ||
| Discover White Pages for given user | Person B as end user | Person B as Requesting Party | ||
| Search/Find Person WP Information | End User Person B as end user | Person B as Requesting Party B | ||
| Request Authorization for WP Information Access | End User Person B as end user | Person B as Requesting Party B | ||
| Grant Authorization for WP Information Access per Policy | Portal Tab WP App behind SAML SP | Authorization Server | ||
| Show WP Information | Portal Tab WP App | Resource Server or a Client of Resource Server |
This simple example already highlights some differences between a SAML-based solution and an UMA-based solution. Note that functions performed by the Portal Tab App are carried out by more than one component in the UMA model. This helps explain the need for a protocol for cooperatively provided services in the UMA model–The Resource Server and Authorization Server need to collaborate to accomplish the usage scenario. Conversely the comparison highlights that some elements of the usage scenario are "out of band" with respect to the SAML model. A full solution would have to be "SAML plus".
...