Oasis Security Services Use Cases And Requirements

Straw Man Draft 1, 25 Jan 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.

The document uses UML-style use-case diagrams to illustrate use cases. A link to the UML home page is provided below, but the following list is probably sufficient as a crash course in UML use-case diagrams:

• Stick figures represents actors or roles in a scenario. These can be human beings or software systems.
• Ellipses represent use cases, i.e. actions or units of functionality in a system.
• Lines between actors and use cases indicate a participation of the actor in the use case.
• A scenario is a group of logically connected use cases.

Requirements

The following are requirements for the standard.

Goals

• [OSSML] should be defined in XML.
• [OSSML] should be easily extensible.
• [OSSML] should allow "binding" to standard Internet protocols, including:
  • standard commercial browsers
  • HTTP as a transport protocol
  • MIME as a packaging protocol
  • SOAP as a messaging protocol
  • ebXML as a messaging protocol
• [OSSML] should define a message format for passing authentication, authorization, and profile information between zones of security administration.
• [OSSML] should support "pushing" data assertions from one zone of security administration to another; and "pulling" from one zone of security administration to another.
• [OSSML] should not be dependent on any particular security or user database format.

Non-Goals

• [OSSML] will not propose any new cryptographic technologies or models for security; instead, the emphasis is on description and use of well-known security technologies utilizing a standard syntax (markup language) in the context of the Internet.
• Non-repudiation services and markup are outside the scope of [OSSML].
• Challenge-response authentication protocols are outside the scope of [OSSML].
• [OSSML] does not provide for negotiation between authorities about trust between domains and realms or the inclusion of optional data. Trust negotiations must be made out-of-band.
• No provision is made for protecting [OSSML] messages from interception by third parties. This is left up to the transport mechanism of choice between authorities.
• No specification is made for providing authorization policies through [OSSML].

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.

Scenario 1: Single Sign-on, Pull Model

Fig 1. Single Sign-on, Pull Model.

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.

Scenario 2: Single Sign-on, Push Model

This scenario is a variation on the single sign-on scenario. It's called the "push model" because the source Web site pushes authentication information to the destination Web site on a back channel in order to determine

This scenario is based on S2ML's "Scenario 1: User-Driven Transactions (Single Sign-on)" and in the pull model section from the AuthXML document.

Fig 2. Single Sign-on, Push Model.

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.

Single Sign-on, Third-Party Security Service

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

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.

Back Office Transaction

Fig 4. Back Office Transaction.

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.

Back Office Transaction, Third-Party Security Service

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

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.

Application Chain

Fig 6. Application Chain.

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.

References

This document is derived from the following sources:

• Security Services Markup Language v0.8a, Prateek Mishra et. al.
• AuthXML: A Specification for Authentication Information In XML v0.3, Evan Prodromou et. al.

Other references that may be useful:

• Oasis Open Security Services Technical Committee, http://www.oasis-open.org/committees/security/index.shtml
.
• Unified Modeling Language (UML), http://www.omg.org/uml/.

Document History

• 25 Jan 2001 -- First draft derived from merge of S2ML and AuthXML specs.