[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 -
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC