RE: [STF] Additional security usage scenarios - More comments

RE: [STF] Additional security usage scenarios - More commentsI agree with
Hal.  S063 was intended for authentication.  SSO for web services would be a
different scenario, and I think it should be in the scenarios doc.

Dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Hal Lockhart
  Sent: Wednesday, August 07, 2002 2:46 PM
  To: 'Steven A. Monetti'; Hugo Haas; www-ws-arch@w3.org
  Subject: RE: [STF] Additional security usage scenarios - More comments


  > |   1. Single Sign-On: Authentication using a Username/Password and
  > |   Transport-Level Security
  >
  > S063 covers this topic. However, S063 isn't finished so it needs to be
  > completed.
  >
  > => Finish S063.

  First, I should point out that the source of this usecase was SAML. The
SAML usecase was explicitly NOT Web Services, it was web SSO based on the
limitations of currently deployed browsers and the mechanisms available in
HTTP. The SAML Browser/artifact and Browser/post profiles are SAML's
responses to these requirements. (Project Liberty has augmented these and
added two further ones.)

  This does not necessarily mean that SSO should NOT be a WSS requirement,
but that the SAML TC did not identify it as such, so this group should make
an explicit decision.

  Cryptographic Authentication methods, such as Kerberos and SSL/TLS with
client certs are inherently SSO, at least from the user's point of view. But
providing SSO in a HTTP basic auth/password environment requires using state
management techniques such as cookies and encoded URLs which would not be
chosen in an ideal world. Given the ability of a Web Services client to
dynamically create SOAP messages and headers, considerably better approaches
are available.

  The next point is that if I am looking at the right document, S063 says
nothing about SSO, only Authentication. Perhaps that is what Hugo meant
about it not being finished, but generally speaking, Authentication does not
necessrily imply SSO.

  [...]

  > |   8. Delegating Trust
  >
  > I don't believe that this is covered by our document yet.
  >
  > => Add scenario about trust delegation.

  It is worth noting that there are two different capabilities being called
delegation in various groups and requirement sets.

  The first, I will call delegation by policy is the ability of an
Authorization policy to say "allow X to do such and such on behalf of Y" and
an identity assertion scheme that allows X to say "I am doing this on behalf
of Y". This approach only solves this specific problem, but it is very
suitable for high volume applications involving many thousands of
authorization decisions per second.

  The second, I will call administrative policy control is the ability to
allow a party to create a policy which allows another party to perform
certain actions. The first party may or may not be allowed to perform these
actions, but the ability to create policy must in turn be controlled by
policy. This can be used to solve the previous requirement, e.g. I can let X
do this on Y's behalf (whether I am Y or not) by creating a policy to that
effect. However, this mechanism may not be suitable for use in high
performance environments. It can also be used to solve the more general
problem of delegating administrative functions.


  > |   9. Access Control Lists
  >
  > I don't think that this is covered by our current document. I was
  > thinking about proposing to it to one of the use cases, but I am still
  > unsure about it. A usage scenario about ACLs may be in order.
  >
  > => Add scenario about ACLs.

  I am not sure if this scenario is supposed to refer specifically to ACLs
or more generally to Authorization Policy. I think the model implied by the
scenario as written is a poor one which does not scale well.

  The SAML/XACML Domain model, which is essentially the same as the IETF and
ISO ones says that information about users attributes and their
authentication methods is (or at least can be) stored separately from
policies about access to specific resources. Authorzation policies can take
information about Authentication acts, user attributes as well as other
kinds of information and make a decision about whether to allow a particular
access request.

  This scales better because policies about specific resources e.g. URLs,
tend to be very volatile and application specific. In this model, users are
given the ability to do things by changing their attributes at an attribute
authority. Changes to authorization policy is typically driven by
application changes.

  Perhaps the intention behind this scenario is what I called administrative
policy control above.

  >
  > |   10. Auditing to Track Security-Related Activities and Incidents
  >
  > Auditing isn't covered by our document.
  >
  > => Add auditing usage scenario.

  What is unclear about this scenario as presented in the Roadmap document,
is what part of this capability would be standardized? Note that there is no
specification relating to Audit shown in Figure 5 of the Roadmap or
mentioned anywhere else in that document. Would the protocol, the file
format, the audit events or something else be standardized?

  Hal