Oasis Security Services Use Cases And Requirements

Straw Man Draft 3, 26 Feb 2001

Purpose

This document describes the requirements and use cases for the Security Assertions Markup Language (SAML) 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, SAML, an XML standard for exchanging authentication and authorization data between security systems.

Notes on This Document

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. Note that no direction or payload of data flow is expressed by the lines between actors and 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 SAML standard.

Goals

• [R-AuthN] SAML should define a data format for authentication assertions, including descriptions of authentication events. This includes time of authentication event and authentication protocol.
• [R-AuthZ] SAML should define a data format for authorization attributes. Authorization attributes ("authz attributes") are attributes of a principal that are used to make authorization decisions, e.g. an identifier, group or role membership, or other user profile information.
• [R-AuthZDecision] SAML should define a data format for recording authorization decisions.
• [R-UserSession] SAML shall support web user sessions.
• [R-Anonymity] SAML will allow assertions to be made about anonymous principals, where "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.).
• [R-Pseudonymity] SAML will allow assertions to be made about principals using pseudonyms for identifiers.
• [R-Message] SAML should define a message format and protocol for distributing SAML data.
• [R-PushMessage] SAML's messaging protocol should support "pushing" data assertions from an authoritative source to a receiver.
• [R-PullMessage] SAML's messaging protocol should support "pulling" data assertions from an authoritative source to a receiver.
• [R-Reference] SAML should define a data format for providing references to authentication and authorization assertions.
• [R-MultiDomain] SAML should enable communication between zones of security administration.
• [R-SingleDomain] SAML should enable communication within a single zone of security administration.
• [R-Signature] SAML assertions and messages should be authenticatable.
• [R-Open] SAML should not be dependent on any particular security or user database format.
• [R-XML] SAML should be defined in XML.
• [R-Extensible] SAML should be easily extensible.
• [R-Bindings] SAML should allow SAML messages to be transported by standard Internet protocols. SAML 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

• SAML 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 SAML.
• Challenge-response authentication protocols are outside the scope of SAML.
• SAML 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 SAML 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 SAML.

Use Cases And Scenarios

This section provides a set of high-level use cases for SAML and use case scenarios that illustrate the use case. They give a very abstract view of the intended use of the SAML 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, for each use case, the mechanics of how the actions are performed is not described. More detail provided in the detailed use case scenarios. Each of these high-level use cases has one or more specializations in the detailed use-case scenarios.

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.

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:

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

Scenario 1-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 2. 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. This document includes authn event description and authz attributions about the Web user.
7. Destination Web site provides resource to Web user.

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

Scenario 1-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 3. 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 sends requests for Web user to use destination resource from destination Web site, pushing the authentication information (authentication assertion) for the user to the destination site. This assertion includes authorization attributes.
4. Destination Web site returns an authz decision reference to Source Web site, recording the decision to allow the user to access the resource.
5. Source Web site provides user with authz decision reference and redirects user to destination Web site.
6. User requests destination resource from destination Web site, providing authz decision reference.
7. Destination Web site provides resource to Web user.

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

Scenario 1-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. Note that the first interaction, between the security service and the first destination site, uses the pull model as described above. The second interaction uses the push model. Either of the interactions could use a different single sign-on model.

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

Steps:

1. Web user authenticates with security service.
2. Security service returns SAML authentication reference to Web user.
3. Web user requests resource from first destination Web site, providing authentication reference.
4. First destination Web site requests authentication document from security service, passing the Web user's authentication reference.
5. Security service provides authentication document to first destination Web site, including authorization attributes and authn event description.
6. First destination Web site provides resource to Web user.
7. Web user requests link to second destination Web site from first destination Web site.
8. First destination Web site requests access authorization from second destination Web site, providing third-party security service authentication document for user.
9. Second destination Web site provides access authorization, returning an authz decision reference.
10. First destination Web site provides authz decision reference to Web user.
11. Web user requests resource from second destination Web site, providing authz decision reference.
12. Second destination Web site provides resource.

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

Scenario 1-3: Single Sign-on, User Session

In this single sign-on scenario, a Web user is logs into a Web site and thus instigates a user session. This session is maintained as the user navigates to other Web sites.

Fig. 5. Single Sign-on, User Session

Steps:

1. A user logs onto the source Web site. This results in the creation of a session on the source Web site.
2. User requests a link to a destination Web site. This link contains an authentication reference/token/ticket.
3. User requests resource represented by link on destination Web site, including reference.
4. Destination Web site requests validation of authentication reference from source Web site.
5. Source Web site returns success or failure, optionally additional session information.
6. Destination Web site returns Web site to user.

Fig. 6. User Session Timeout

Assume that the user has gone beyond the timeout limit on the source Web site.

1. The source Web site will query each participating Web site to determine if the user has been active on their Web site.
2. If the user has not been active on any of the destination Web sites within the timeout period, the destination Web sites are instructed to delete the session.

Fig. 6. User Session Logout

Logout

1. User logs out of the source Web site.
2. Each of the destination Web sites are instructed to delete the session.

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

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 5. Authorization Service.

Steps:

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

Scenario 2-1: Application Chain

This scenario illustrates using SAML 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 6. 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, including authorization attributes for the Web user, and authn event description.
7. Application performs application function for Web server.
8. Web server generates dynamic resource for Web user.

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

Use Case 3: Back Office Transaction

In this use case, two agents, a buyer and a seller, attempt to execute a business transaction.

Fig 7. Back Office Transaction.

1. Buyer and seller authenticate that their partner in the transaction is the partner they expect to transact with.
2. Buyer and seller check permission of partner to execute transaction.
3. Buyer and seller execute the transaction.

Scenario 3-1: 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 8. 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. Authentication documents include authz attributes and authn event description.

Associated requirements: [R-AuthN], [R-PushMessage], [R-AuthZ], [R-MultiDomain].

Scenario 3-2: 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 9. 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. Authentication documents include authz attributes and authn event description.

Associated requirements: [R-AuthN], [R-AuthZ], [R-PushMessage].

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.
• 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.
• 26 Feb 2001 -- Third draft.
  • Changed placeholder "[OSSML]" to new, official "SAML".
  • Re-ordered scenarios so that each group of scenarios followed an associated use case.
  • Rephrased use case scenario 1-2 per Nigel Edwards.
  • Updated use case scenario 1-3 per UC-1-02:ThirdParty.
  • Added [R-Anonymity].
  • Added [R-Pseudonymity].
  • Noted exchange of authz attributes, per UC-1-08:AuthZAttrs.
  • Added [R-AuthZDecision] and noted exchange of authz decisions, per UC-1-09:AuthZDecisions.
  • Edited [R-AuthN] and noted exchange of authn event data, per UC-1-10:AuthNEvent.
  • Added user session use case, per UC-3-1.