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:
- 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.
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:
- Boxes at the top of the diagram represent an actor in the
scenario.
- Arrows with a solid head represent a message sent from one
actor to another. The arrow points from sender to receiver.
- Arrows with a line head represent the return value of a
message. The arrow points from the receiver of the earlier
message to the sender.
- A dotted line ("swim lane") running down the diagram from
a box indicates that arrows whose endpoints (tail or head) is
on the line apply to that actor.
- Intersections between arrows and dotted lines are
meaningless.
- Vertical layout represents time. Messages (arrows) farther
down on the page happen after messages higher on the
page.
- Horizontal layout has no formal meaning. Since
right-pointing arrows look better, actors that initiate a
scenario tend to appear leftward of actors they send messages
to.
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
- [R-AuthC] [OSSML] should
define a data format for authentication assertions.
- [R-AuthZ] [OSSML] should
define a data format for authorization attributes, including
profile information.
- [R-Message] [OSSML] should
define a message format and protocol for distributing [OSSML]
data.
- [R-PushMessage] [OSSML]'s The
messaging protocol should support "pushing" data assertions
from an authoritative source to a receiver.
- [R-PullMessage] [OSSML]'s
messaging protocol should support "pulling" data assertions
from an authoritative source to a receiver.
- [R-Reference] [OSSML]
should define a data format for providing references to
authentication and authorization assertions.
- [R-MultiDomain] [OSSML]
should enable communication between zones of security
administration.
- [R-SingleDomain] [OSSML]
should enable communication within a single zone of security
administration.
- [R-Signature] [OSSML]
assertions and messages should be authenticatable.
- [R-Open]
[OSSML] should not be dependent on any particular security
or user database format.
-
[R-XML] [OSSML] should be
defined in XML.
-
[R-Extensible] [OSSML] should
be easily extensible.
-
[R-Bindings] [OSSML] should
allow [OSSML] messages to be transported by standard Internet
protocols. [OSSML] should define bindings of the message
protocol to at least the following protocols:
-
standard commercial browsers
-
HTTP as a transport protocol
-
MIME as a packaging protocol
-
XML Protocol as a messaging protocol
-
ebXML as a messaging protocol
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].
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.

Fig 1. Single
Sign-on.
Steps:
- Web user authenticates to the source Web site.
- 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.

Fig
2. Authorization Service.
Steps:
- User accesses a resource controlled by PEP.
- 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.

Fig 3. Single Sign-on, Pull Model.
Steps:
-
Web user authenticates with source Web site.
-
Web user requests link to destination Web site.
-
Source Web site provides user with authentication reference
(AKA "name assertion reference"), and redirects user to
destination Web site.
-
Web user requests destination Web site resource, providing
authentication reference.
-
Destination Web site requests authentication document ("name
assertion") from source Web site, passing authentication
reference.
-
Source Web site returns authentication document.
-
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.

Fig 4. Single Sign-on, Push
Model.
Steps:
-
Web user authenticates with source Web site.
-
Web user requests link to destination Web site.
-
Source Web site requests authorization for Web user to use
destination resource from destination Web site.
-
Destination Web site returns authorization reference to Source
Web site.
-
Source Web site provides user with authorization reference
and redirects user to destination Web site.
-
User requests destination resource from destination Web site,
providing authorization reference.
-
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.

Fig 5. Single Sign-on, Third-Party Security Service.
Steps:
-
Web user authenticates with security service.
-
Security service returns [OSSML] authentication reference to
Web user.
-
Web user requests resource from destination Web site,
providing authentication reference.
-
Destination Web site requests authentication document from
security service, passing the Web user's authentication
reference.
-
Security service provides authentication document to
destination Web site.
-
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.

Fig 6. Back Office Transaction.
Steps:
-
Buyer authenticates with buyer security system.
-
Buyer security system provides authentication document to buyer.
-
Seller authenticates with seller security system.
-
Seller security system provides authentication document to
seller.
-
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.

Fig 7. Back Office Transaction, Third Party
Security Service.
Steps:
-
Buyer authenticates with security service.
-
Security service provides authentication document to buyer.
-
Seller authenticates with security service.
-
Security service provides authentication document to
seller.
-
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.

Fig 8. Application Chain.
Steps:
-
Web user authenticates with enterprise security system. Note
that authentication may be through e.g. the Web server.
-
Enterprise security system provides an authentication
reference to Web user.
-
Web user requests a dynamic resource from Web server,
providing authentication reference.
-
Web server requests application function from application on
behalf of Web user, providing Web user's authentication
reference.
-
Application requests authentication document from enterprise
security system, corresponding to Web user's authentication
reference.
-
Enterprise security system provides authentication document.
-
Application performs application function for Web server.
-
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:
-
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:
Document History
-
25 Jan 2001 -- First draft derived from merge of S2ML and AuthXML specs.
-
9 Feb 2001 -- Second
draft.
- Incorporated comments from Use Case subcommittee of
Oasis Security Services TC.
- Added set of high-level use cases.
- Changed diagrams of detailed use case scenarios to use
sequence diagrams instead of use case diagrams.
- Added description of each use-case scenario and list of
requirements flowing from the scenario.
- Added draft glossary (as link).
- Added issues list (as link).
- Gave requirements labelled names for easier
reference.
- Incorporated and merged requirements list from Core
Assertions subcommittee of Oasis Security Services
TC (by Philip Hallam-Baker).
- Corrected various editorial mistakes.