RE: Issue Group 11: Authorization Use Case

[Darren Platt <dplatt@securant.com>]

My understanding is that while Irving was going to write up this issue
group, it was not to be voted for this Friday's round of voting - because we
haven't given Irving or the rest of the group enough time to review the
issues or the ballot.

In my opinion, we have already shortened the cycle for the issue groups 1,
3, and 5 as much as possible, and to try to add 11 would be a mistake.

I would like to know the rest of the group's recollection of our decision on
yesterday's concall - please let me know.

Thanks,

Darren



> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Thursday, February 22, 2001 9:44 AM
> To: 'Irving Reid '; 'security-use@lists.oasis-open.org '
> 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
> Darren
> sent around, available on line at
> http://unique.outlook.net/~evan/a2mluc/issues.html
>
>
>
> 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
> action?
>
> 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
> the
> resource also controls the policies at the Policy Decision Point
> corresponding to those resources.
>
>
> Scenario N: Authorization Service
>
> See Figure at
> http://unique.outlook.net/~evan/a2mluc/AuthorizationService.png
>
>
> Steps:
>
> 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
> for
> user to access resource.
> 5. Security system decides on user's authorization and provides
> permission
> information.
> 6. Application provides resource to user.
>
>
>
> ISSUE:[UC-11-02:AuthzFirstContact] A second scenario for the
> Authorization
> 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;
> there
> is not a separate authentication phase between the user and the security
> system.
>
> Steps:
>
> 1. Client sends a single message containing both an authentication
> request
> and a resource request, to the application. A typical example would be
> an
> HTTP request with a client certificate or HTTP Basic Auth username and
> password.
>
> 2. The application sends a combined authentication and authorization
> request
> 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
> requested
> resource to the client.
>
> 5. On subsequent requests, the client makes simple resource requests
> (including the authentication reference). These requests are identical
> to
> those in steps 3-6 of Scenario N.
>
>
>
> Proposed ballot questions:
> ------------------------------------------------------------------------
> ---
> ISSUE:[UC-11-01:AuthzUseCase]
>
> (a) Should SAML include a use case describing an authorization service,
> as
> described above in Scenario N?
>
> Resolution: Yes/No
>
> ------------------------------------------------------------------------
> ---
> ISSUE:[UC-11-02:AuthzFirstContact]
>
> (a) Should SAML include a scenario for an authorization service that
> also
> supports user authentication?
>
> Resolution: Yes/No
>
> (b) Should SAML include a scenario where authentication and
> authorization
> requests can be combined in a single message exchange?
>
> [NOTE: I think this is dangerously close to protocol design, which
> doesn't
> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
>