Issue Group 1 - SSO - Straw Ballot

[Darren Platt <dplatt@securant.com>]

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.

UnknownPartner.png

SingleSignOnThirdPartySecurityService1.png

SingleSignonPushModelRundgren.png

SingleSignonFirstContact.png