[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Issue Group 1 - SSO - Straw Ballot
Attached is a write-up of the issues related to SSO (IssueGroup1.txt), with the goal of formatting them in such a way that it is possible to vote on some resolution. My goal is to vote on them on our call on Wednesday, where people will be asked to choose one of the possible resolutions listed for each issue (or abstain). The attached issue group list is a text file, and it contains references to the attached graphics. If there is some information or argument missing in these write-ups, please let me know before end of day Friday so I can attempt to resolve it. I hope to then distribute a final 'ballot' on Monday which will contain writeups for issue groups 1-SSO Variations, 3-Sessions, and 5-AuthC Protocols, which we can then use to vote. I will be sending out a proposed subcommittee voting process for your review today if possible - if not tomorrow. If it seems workable to everyone, I will propose this process on the call on Wednesday. It would be great if we could get most of the discussion out of the way on the list beforehand so that Wednesday can be productive. Regards, Darren Darren Platt Principal Technical Evangelist Securant Technologies 1 Embarcadero Center, Floor 5 San Francisco, CA 94111 tel - (415) 315-1529 fax - (415) 315-1545 http://www.securant.com/ -----------------------------
Group 1: Single Sign-on Push/Pull Variations ISSUE[UC-1-01:Shibboleth] The Shibboleth security system for Internet 2 (http://middleware.internet2.edu/shibboleth/index.shtml) is closely related to the [OSSML] effort. An attempt has been made to address the requirements and design of Shibboleth in the [OSSML] requirements document to allow implementation of [OSSML] to be part of, or at least interoperable with, Shibboleth implementations. In particular, the following issues have been introduced to address Shibboleth requirements: UC-1-04:ARundgrenPush UC-1-06:Anonymity UC-1-07:Pseudonymity UC-1-10:UntrustedPartners UC-4-04:SecurityDiscovery UC-9-03:PrivacyStatement UC-9-04:RuntimePrivacy If these issues, along with the straw man 2 document, have addressed the requirements of Shibboleth, then the subcommittee can address each issue on its own, rather than Shibboleth as a monolithic problem. Possible Resolutions: 1. The above list of issues, combined with the straw man 2 document, address the requirements of Shibboleth, and no further investigation of Shibboleth is necessary. 2. Additional investigation of Shibboleth requirements are needed. ISSUE[UC-1-02:ThirdParty] Use case scenario 3 (single sign-on, third party) describes a scenario in which a Web user logs in to a particular 3rd-party security provider which returns an authentication reference that can be used to access multiple destination Web sites. Is this different than Use case scenario 1 (single sign-on, pull model)? If not, should it be removed from the use case and requirements document? As written, the use case is not truly different from use case scenario 1. However, if the use case scenario is expanded to include multiple destination sites, the importance of this use case becomes more apparent. The following edition to the single sign-on, third party use case scenario would be added: 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. [Diagram: SingleSignOnThirdPartySecurityService.png] Steps: 1. Web user authenticates with security service. 2. Security service returns [OSSML] 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. 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. 10. First destination Web site provides authorization reference to Web user. 11. Web user requests resource from second destination Web site, providing authorization reference. 12. Second destination Web site provides resource. Possible Resolutions: 1. Edit the current third-party use case scenario to feature passing a third-party authentication assertion from one destination site to another. 2. Remove the third-party use case scenario entirely. ISSUE[UC-1-03:ThirdPartyDoable] Questions have arisen whether use case scenario 3 is doable with current Web browser technology. An alternative is using a Microsoft Passport-like architecture or scenario. It seems that at least one possible solution for the third-party security system exists -- that each destination site pass the authentication assertion from the third party security service to the next destination site, just as in peer source and destination scenarios such as use case scenarios 1 and 2. Therefore, it seems that the scenario is at least theoretically implementable. It will be up to the other subcommittees and implementors of the standard to decide on how to define that implementation. Possible Resolutions: 1. The use case scenario should be removed because it is unimplementable. 2. The use case scenario is implementable, and whether it should stay in the document or not should be decided based on other factors. ISSUE[UC-1-04:ARundgrenPush] Anders Rundgren has proposed on security-use an alternative to use case scenario 2 (single sign-on, push model). The particular variation is that the source Web site requests an authorization profile for a resource (e.g., the credentials necessary to access the resource) before requesting access. [Diagram: SingleSignonPushModelRundgren.png] Possible Resolutions: 1. Use this variation to replace scenario 2 in the use case document. 2. Add this variation as an additional scenario in the use case document. 2. Do not add this use case scenario to the use case document. ISSUE[UC-1-05:FirstContact] A variation on the single sign on use case that has been proposed is one where the Web user goes directly to the destination Web site without authenticating with a definitive authority first. A single sign-on use case scenario would be added as follows: In this single sign-on scenario, the user does not first authenticate with their home security domain. Instead, they go directly to the destination Web site, first. The destination site must then redirect the user to a site they can authenticate at. The situation then continues as if in a single sign-on, push model scenario. [SingleSignonFirstContact.png] Steps: 1. Web user requests resource from destination Web site. 2. Destination Web site determines that the Web user is unauthenticated. It chooses the appropriate home domain for that user (deployment dependent), and redirects the Web user to that source Web site. 3. Web user authenticates with source Web site. 4. Source Web site provides user with authentication reference (AKA "name assertion reference"), and redirects user to destination Web site. 5. Web user requests destination Web site resource, providing authentication reference. 6. Destination Web site requests authentication document ("name assertion") from source Web site, passing authentication reference. 7. Source Web site returns authentication document. 8. Destination Web site provides resource to Web user. Possible Resolutions: 1. Add this use case scenario to the use case document. 2. Do not add this use case scenario to the use case document. ISSUE[UC-1-06:Anonymity] What part does anonymity play in [OSSML] conversations? Can assertions be for anonymous parties? Here, "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.). A requirement for anonymity would state: [R-Anonymity] [OSSML] will allow assertions to be made about anonymous principals. Possible Resolutions: 1. Add this requirement to the use case and requirement document. 2. Do not add this requirement. ISSUE[UC-1-07:Pseudonymity] What part do pseudonyms play in [OSSML] conversations? Can assertions be made about principals using pseudonyms? Here, a pseudonym is an attribute in an assertion that identifies the principal, but is not the identifier used in the principal's home domain. A requirement for pseudonymity would state: [R-Pseudonymity] [OSSML] will allow assertions to be made about principals using pseudonyms for identifiers. Possible Resolutions: 1. Add this requirement to the use case and requirement document. 2. Do not add this requirement. ISSUE[UC-1-08:AuthZAttrs] It's been pointed out that the concept of an "authentication document" used in the use case and requirements document does not clearly specify the inclusion of authz attributes. Here, authz attributes are attributes of a principal that are used to make authz decisions, e.g. an identifier, or group or role membership. Since authz attributes are important and are required by [R-AuthZ], it has been suggested that the single sign-on use case scenarios specify when authz assertions are passed between actors. Possible Resolutions: 1. Edit the use case scenarios to specify passing authz attributes with authentication documents. 2. Do not specify the passing of authz attributes in the use case scenarios. ISSUE[UC-1-09:AuthZDecisions] The current use case and requirements document mentions "Access Authorization" and "Access Authorization References." In particular, this data is a record of a authorization decision made about a particular principal performing a particular action on a particular resource. It would be more clear to label this data as "AuthZ Decision Documents" to differentiate from other AuthZ data, such as AuthZ attributes or AuthZ policy. To this point, the mentions of "access authorization" would be changed, and a new requirement would be added as follows: [R-AuthZDecision] [OSSML] should define a data format for recording authorization decisions. Possible Resolutions: 1. Edit the use case scenarios to use the term "authz decision" and add the [R-AuthZDecision] requirement. 2. Do not make these changes. ISSUE[UC-1-10:UnknownParty] The current straw man 2 document does not have a use case scenario for exchanging data between security services that are previously unknown to each other. For example, a relying party may choose to trust assertions made by an asserting party based on the signatures on the AP's digital certificate, or through other means. The following use case scenario would illustrate using assertions from an unknown party. In this scenario, an application service provider has a policy to allow access to resources for all full-time students at accredited 4-year universities and colleges. It would be difficult for the application service provider to maintain agreements with hundreds of such organizations in order to verify assertions made by those parties. Instead, it chooses to check the key of the asserting party to ensure that the asserting party is a 4-year university. [Diagram: UnknownPartner.png] 1. Student authenticates to university security system. 2. University provides authentication document to student application, including authentication event data and authorization attributes. 3. Student application requests resource from application service provider. Request includes authentication document. 2. Application service provider makes a trust decision about the authc and authz data, based on the key used to sign the assertion. It determines that the signing party is an accredited 4-year university, based on a signature on the key made by an accrediting organization. 3. Application service provider makes an authorization decision based on the authz attributes of the student. 4. Application service provider returns resource to the student. Possible Resolutions: 1. Add this use case scenario to the use case document. 2. Do not add this use case scenario to the use case document. ISSUE[UC-1-11:AuthCEvents] It is not specified in straw man 2 what authentication information is passed between parties. In particular, specific information about authc events, such as time of authc and authc protocol are alluded to but not specifically called out. The use case scenarios would be edited to show when information about authc events would be transferred, and the requirement for authc data would be edited to say: [R-AuthC] [OSSML] should define a data format for authentication assertions, including descriptions of authentication events. Possible Resolutions: 1. Edit the use case scenarios to specifically define when authc event descriptions are transferred, and edit the R-AuthC requirement. 2. Do not change the use case scenarios or R-AuthC requirement. ISSUE[UC-2-01:AddPolicyAssertions] Some use cases proposed on the security-use list (but not in the straw man 1 document) use a concept of a "policy document." In concept a policy document is a statement of policy about a particular resource, such as that user "evanp" is granted "execute" privileges on file "/usr/bin/emacs." Another example may be that all users in domain "Acme.com" with role "backup administrator" may perform the "shutdown" method on resource "mail server," during non-business hours. Use cases where policy documents are exchanged, and especially activities like security discovery as in UC-4-04:SecurityDiscovery, would require this type of assertion. If these use cases and/or services were adapted, the term "policy document" should be used. In addition, the following requirement would be added: [R-Policy] [OSSML] should define a data format for security policy about resources. In addition, the explicit non-goal for authorization policy would be removed. Possible Resolutions: 1. Remove the non-goal, add this requirement, and refer to data in this format as "policy documents." 2. Maintain the non-goal, leave out the requirement.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC