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. Close this issue.

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.

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 implementers of the standard to decide on how to define that implementation.

Possible Resolutions:

1. The use case scenario should be removed because it is not ‘implementable’.

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.

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.

3. 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.

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 for the SSO scenarios.

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 clearer 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.

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 authN 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.