Oasis Security Services Use Cases And Requirements

Straw Man Draft 2, 9 Feb 2001

Purpose

This document describes the requirements and use cases for the XML standard derived by the Oasis Security Services Technical Committee.

Introduction

This document provides an initial set of use cases and requirements for the Oasis Security Services Technical Committee's (TC's) ultimate product, an XML standard for exchanging authentication and authorization data between security systems.

Notes on This Document

At the time of the initial draft of this document, no name for the XML standard derived by the Oasis Security Services Technical Committee had been decided on. As a placeholder, the phrase "[OSSML]" (Oasis Security Services Markup Language) has been used. This is not final and these placeholders will be replaced at a future date.

Requirements are specified as a list of goals and non-goals for the project.

Use cases in this document are illustrated with UML (Unified Modelling Language) diagrams. A link to the UML home page is provided below. UML diagrams are analysis and design tools, and each diagram format can support multiple levels of abstraction. In this document a balance has been struck between using a standard diagram format for requirements elaboration, and maintaining a high level of abstraction.

The document uses UML-style use-case diagrams to illustrate high-level use cases. The following list is probably sufficient as a crash course in UML use-case diagrams:

Use-case diagrams capture high-level functionality of a system or interaction without providing excessive implementation detail.

The document uses UML sequence diagrams to illustrate detailed use case scenarios. For quick reference, a sequence diagram works as follows:

Note that sequence diagrams are often used for more concrete design, and that actors and messages are often objects and object methods. They provide value for this document in that they give a clearly ordered message layout. The actors and messages in the sequence diagrams below are more properly roles in a scenario and actions associated with that scenario.

Readers will probably be interested in the accompanying glossary and issues list.

Requirements

The requirements describe the scope of the [OSSML] standard.

Goals

Non-Goals

High-level Use Cases

This section provides a set of high-level use cases for [OSSML]. They give a very abstract view of the intended use of the [OSSML] format. Each use case has a short description, a use case diagram in UML format, and a list of the steps involved in the case.

Note that the mechanics of how the actions are performed is not described. More detail provided in the detailed use case scenarios in the next section of this document. Each of these high-level use cases has one or more specializations in the detailed use-case scenarios.

Use Case 1: Single Sign-On

In this use case, a Web user authenticates with a Web site. The Web user then uses a secured resource at another Web site, without directly authenticating to that Web site.

Single
    Sign-On
Fig 1. Single Sign-on.

Steps:

  1. Web user authenticates to the source Web site.
  2. Web user uses a secured resource at the destination Web site.

Use Case 2: Authorization Service

In this use case, a user attempts to access a resource or service. The security controller for that resource -- a policy enforcement point or PEP -- checks the user's authorization to access the resource with a policy decision point or PDP.

The PDP provides an authorization service to the PEP.

Authorization Service
Fig 2. Authorization Service.

Steps:

  1. User accesses a resource controlled by PEP.
  2. PEP checks permission for user to access resource with PDP.

Detailed Use Case Scenarios

Each of the following is a use-case scenario describing a goal for usage of [OSSML]. These scenarios can be used to validate designs for other parts of the [OSSML] standard.

Each scenario contains a short description of the scenario, a UML sequence diagram illustrating the action in the scenario, a description of each step, and a list of requirements that are related to the scenario.

Scenario 1: Single Sign-on, Pull Model

This scenario is an elaboration of the Single Sign-on use case. In this model, the destination Web site pulls authentication information from the source Web site based on references or tokens provided by the Web user.

Single Sign-on, Pull
    Model
Fig 3. Single Sign-on, Pull Model.

Steps:

  1. Web user authenticates with source Web site.
  2. Web user requests link to destination Web site.
  3. Source Web site provides user with authentication reference (AKA "name assertion reference"), and redirects user to destination Web site.
  4. Web user requests destination Web site resource, providing authentication reference.
  5. Destination Web site requests authentication document ("name assertion") from source Web site, passing authentication reference.
  6. Source Web site returns authentication document.
  7. Destination Web site provides resource to Web user.

Associated requirements: [R-AuthC], [R-PullMessage], [R-MultiDomain], [R-Bindings] (standard commercial browsers), [R-Reference].

Scenario 2: Single Sign-on, Push Model

This scenario is a variation on the Single Sign-on use case. It's called the "push model" because the source Web site pushes authentication information to the destination Web site.

Single Sign-on, Push
    Model
Fig 4. Single Sign-on, Push Model.

Steps:

  1. Web user authenticates with source Web site.
  2. Web user requests link to destination Web site.
  3. Source Web site requests authorization for Web user to use destination resource from destination Web site.
  4. Destination Web site returns authorization reference to Source Web site.
  5. Source Web site provides user with authorization reference and redirects user to destination Web site.
  6. User requests destination resource from destination Web site, providing authorization reference.
  7. Destination Web site provides resource to Web user.

Associated requirements: [R-AuthC], [R-AuthZ], [R-PullMessage], [R-MultiDomain], [R-Bindings] (standard commercial browsers), [R-Reference].

Scenario 3: Single Sign-on, Third-Party Security Service

In this single sign-on scenario, a third-party security service provides authentication assertions for the user. Multiple destination sites can use the same authentication assertions to authenticate the Web user.

Single Sign-on, Third Party Security Service
Fig 5. Single Sign-on, Third-Party Security Service.

Steps:

  1. Web user authenticates with security service.
  2. Security service returns [OSSML] authentication reference to Web user.
  3. Web user requests resource from destination Web site, providing authentication reference.
  4. Destination Web site requests authentication document from security service, passing the Web user's authentication reference.
  5. Security service provides authentication document to destination Web site.
  6. Destination Web site provides resource to Web user.

Associated requirements: [R-AuthC], [R-PullMessage], [R-MultiDomain], [R-Bindings] (standard commercial browsers), [R-Reference].

Scenario 4: Back Office Transaction

In this scenario, two parties, buyer and seller, wish to perform a transaction. Each authenticates to a security system responsible to their own security zone (buyer security system and seller security system, respectively). They exchange authentication data provided by their security systems to authenticate the transaction.

Back Office
    Transaction
Fig 6. Back Office Transaction.

Steps:

  1. Buyer authenticates with buyer security system.
  2. Buyer security system provides authentication document to buyer.
  3. Seller authenticates with seller security system.
  4. Seller security system provides authentication document to seller.
  5. Buyer and seller execute transaction, providing authentication documents to each other.

Associated requirements: [R-AuthC], [R-PushMessage], [R-MultiDomain].

Scenario 5: Back Office Transaction, Third-Party Security Service

This scenario is similar to scenario 4. The same two parties, buyer and seller, wish to perform a transaction. In this case, however, each authenticates to a third-party security service responsible. The buyer and seller exchange authentication data provided by their security systems to authenticate the transaction.

Back Office
    Transaction, Third Party Security Service
Fig 7. Back Office Transaction, Third Party Security Service.

Steps:

  1. Buyer authenticates with security service.
  2. Security service provides authentication document to buyer.
  3. Seller authenticates with security service.
  4. Security service provides authentication document to seller.
  5. Buyer and seller execute transaction, providing authentication documents to each other.

Associated requirements: [R-AuthC], [R-PushMessage].

Scenario 6: Application Chain

This scenario illustrates using [OSSML] within a security zone. A Web user requests a dynamic resource from a Web server. The Web server passes authentication information to an application so that the application can check the user's authorization to execute a method.

Application Chain
Fig 8. Application Chain.

Steps:

  1. Web user authenticates with enterprise security system. Note that authentication may be through e.g. the Web server.
  2. Enterprise security system provides an authentication reference to Web user.
  3. Web user requests a dynamic resource from Web server, providing authentication reference.
  4. Web server requests application function from application on behalf of Web user, providing Web user's authentication reference.
  5. Application requests authentication document from enterprise security system, corresponding to Web user's authentication reference.
  6. Enterprise security system provides authentication document.
  7. Application performs application function for Web server.
  8. Web server generates dynamic resource for Web user.

Associated requirements: [R-AuthC], [R-PullMessage], [R-SingleDomain], [R-Bindings] (standard commercial browsers), [R-Reference].

References

This document is derived from the following sources:

Other references that may be useful:

Document History