OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Issue Group 11: Authorization Use Case

I realize we had agreed not to start a 
discussion, but this issue group has entered
into the closing
stage very recently. So I do have a question
for you?

How is this use-case different from the existing
use case 2 in Strawman 2? I should have brought this
up in the call yesterday. My belief is your scenario N
is precisely an instance of use case 2.

I have no problem living with the ballot as it is. 
A little redundancy wont damage us (I think). My
concern is that I am missing some key details.

- prateek 

-----Original Message-----
From: Irving Reid
To: security-use@lists.oasis-open.org
Sent: 2/22/01 11:20 AM
Subject: Issue Group 11: Authorization Use Case

I've started with the text from the strawman 2 issues document that
sent around, available on line at

ISSUE:[UC-11-01:AuthzUseCase] The use case scenarios outlined in straw
man 2
include explicitly only authn use cases. Should a use case featuring an
authz conversation, such as a policy enforcement point (PEP) querying a
policy decision point (PDP) for authorization for a user to execute an

The use case would be included as follows:

This use case illustrates an authorization service that provides
authorization checks for resource access. This authorization service is
expected to operate within a single security domain, where the owner of
resource also controls the policies at the Policy Decision Point
corresponding to those resources.

Scenario N: Authorization Service

See Figure at


1. User authenticates to security system.
2. Security system provides authentication assertion to user.
3. User requests resource from application (where the resource can be
execution of an action, a file, a database record, etc.), providing
authentication assertion.
4. Application requests a check of permissions from the security server
user to access resource.
5. Security system decides on user's authorization and provides
6. Application provides resource to user.

ISSUE:[UC-11-02:AuthzFirstContact] A second scenario for the
use case combines first contact single-sign-on
(ISSUE:[UC-1-05:FirstContact]), authentication
(ISSUE:[UC-5-01:AuthCProtocol]) and authorization.

Scenario N+1: Authorization Service, First Contact with Authentication

In this scenario, the client makes contact only with the application;
is not a separate authentication phase between the user and the security


1. Client sends a single message containing both an authentication
and a resource request, to the application. A typical example would be
HTTP request with a client certificate or HTTP Basic Auth username and

2. The application sends a combined authentication and authorization
to the security system.

3. The security system replies with an authentication reference
([R-Reference]) and permission information.

4. The application returns the authentication reference and the
resource to the client.

5. On subsequent requests, the client makes simple resource requests
(including the authentication reference). These requests are identical
those in steps 3-6 of Scenario N.

Proposed ballot questions:

(a) Should SAML include a use case describing an authorization service,
described above in Scenario N?

Resolution: Yes/No


(a) Should SAML include a scenario for an authorization service that
supports user authentication?

Resolution: Yes/No

(b) Should SAML include a scenario where authentication and
requests can be combined in a single message exchange?

[NOTE: I think this is dangerously close to protocol design, which
really belong in the use case document. I'm putting this in to give
people a
chance to discuss whether it belongs; I don't think it does. - irving -

Resolution: Yes/No

 - irving -

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-use-request@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC