This As the NSTIC work program evolves, we can expect to see multiple proposed solutions put forward that promise to deliver a new generation of online services. To the extent that the various solutions are competing for adoption, it will be necessary to evaluate them against each other for relative costs and benefits. Such comparisons will be quite challenging because proposed solutions will be built on disparate and seemingly incommensurable models (architectures, protocol stacks).
What follows is intended as a first step toward an analytical framework that would allow us to meaningfully compare and contrast widely different solutions to given usage scenarios in the general space of web security. For a given problem, SAML-federation-based solutions To take an example a SAML-based solution to a given problem might initially appear quite orthogonal to , for example, UMA-based solutions, even for solution to the same usage scenario. Yet in ambitious ventures such as NSTIC, we need to be able to make meaningful comparisons between drastically different proposed solutions.The initial goal here problem. Yet for the reasons cited above it will be important to be able to evaluate and compare one against the other.
A prerequisite step 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 commonly discussed multi-capability service and application models. The services and applications are the typical units of analysis when a given model is being presentedthat correspond to familiar protocol-based solution families.
The following is offered as an introductory example. Imagine that a university offers students a tab in its portal service they can use 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 the same institutioninstitutions within a specified set.
Table I: Atomic functionality required to implement such a management tool and the associated online white pages editing and delivery tool with their composition under two different models:
| Step | Name | Relevant actor actors or componentcomponents in SAML federation model | Relevant actor actors or componentcomponents in UMA model | ||
|---|---|---|---|---|---|
| 1 | Request | AuthenticationEnd User A | Resource Owner | ||
| Authenticate | Authentication Service fronting SAML IdP | Authentication Service fronting Resource Server | |||
| Request Authorization to edit White Page (WP) Information | End User A | Requesting Party A | |||
| to edit one's own protected White Page (WP) information | Person A as end user --> WP Editing App behind SAML SP | Person A as end user --> WP Client App on Resource Server (RS) | |||
| 2 | Challenge for Identity | AuthN Service fronting SAML IdP --> Person A as end user | Authorization Server (AS) protecting RS --> Person A as end user | ||
| 3 | Claim Identity | Person A as end user --> AuthN Service fronting SAML IdP | Person A as Resource Owner --> Authorization Server (AS) protecting RS | ||
| 4 | Verify Claimed Identity | Authentication Service fronting SAML IdP --> Person A as end user | AS protecting RS --> Person A as Resource Owner (RO) | ||
| 5 | Grant Authorization to edit WP Information | Portal Tab WP Editing App behind SAML SP Authorization Server--> Person A as end user | AS protecting RS --> Person A as RO | ||
| 6 | Edit WP Information | End User A | Resource Owner | Person A as end user --> WP Editing App behind SAML SP | Person A as RO --> WP Client App on RS |
| 7 | Set Access Policy for WP Information | End User A | Resource Owner(Done on behalf of Person A by IdP admin per attribute release policy) | Person A as RO --> AS | |
| 8 | Persist Access Policy for WP Information | Not SAML Specified | Authorization Server | ||
| Put WP Information Online | Portal Tab | Resource Server | |||
| SAML Attribute Release Config Files | AS | ||||
| 9 | Make WP Information Available Online | WP App | Resource Server | ||
| 10 | Discover White Pages for given user | Person B as end user | Service Registration; Person B as Requesting Party | ||
| 11 | Search/Find Person WP Information | End User Person B as end user | Person B as Requesting Party B | ||
| 12 | Request Authorization for WP Information Access | End User Person B as end user | Person B as Requesting Party | ||
| 13 |
| ||||
| 14 | Grant Authorization for WP Information Access per Policy | Portal Tab WP App behind SAML SP | Authorization Server | ||
| 15 | 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 WP App in the SAML model are carried out by more than one component in the UMA model. This helps explain the need in the UMA model for a protocol for cooperatively provided services in the UMA model–The services–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" scope with respect to the SAML model. A In other words, a full solution would have to be "SAML plus".
...