Re: [wsrp][security] R401

[Rich Thompson <richt2@us.ibm.com>]

I would suggest rewording R401 to:
      The specification MUST define how secure transport MAY be
      used for communications between portal and portlet.

A related requirement should then also be included:
      The specification MUST define how document security standards
      MAY be used for messages between portal and portlet.



                                                                                                                    
                      "Cassidy, Mark"                                                                               
                      <mcassidy@Netegri        To:       "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>  
                      ty.com>                  cc:                                                                  
                                               Subject:  [wsrp][security] Agenda for 6/5 telecon                    
                      06/04/2002 07:53                                                                              
                      PM                                                                                            
                                                                                                                    
                                                                                                                    



I've begun to take the security requirements we have documented to date and
map to current standards.  Using the numbering scheme assigned by Carsten,
I've started with the first couple requirements and updated the language
used as well as begun to capture content that would go into the spec
chapter.  In the process, I've identified a number of issues/questions that
I'd like to focus tomrrow's telecon on.  Below is outline and discussion
points behind the first two requirements.

Time:  8:00 a.m. PST(11:00 a.m. EST, 5:00 p.m. CET)
Reservationless-Plus Toll Free Dial-In Number: 877.450.3529
Reservationless-Plus International Dial-In Number: +1.706.679.6653
Conference Code: 4254674195

**************************

Chapter 5   Security
Preamble key points:

- WSRP is exposed to many of the same security issues that today's web
services-based systems are susceptible to.  It is the goal within WSRP to
leverage existing standards efforts focusing on web services security as
much as possible, and to identify solutions that provide the broadest
possible interoperability based on widely used infrastructure components.

- Reference to existing documents discussing  of security issues/threats

- WSRP context for security issues:
  o Trust between portal and portlet(authentication)
  o Handling of end user identity and personal information(authentication
and confidentiality)
  o Secure transmission of data(confidentiality)
  o Access control(policy)

- Discussion of transport-based and document-based approaches to addressing
security issues

- Pointers to relevant standards which WSRP will aim to leverage


Spec details behind requirements:

Number             Type        Description             Comment
R401         MUST        The specification MUST support the use of secure
transport
for communications between portal and portlet
Use of transport-level security is optional.

Applicable standards widely in use:   SSL/TLS.  This mechanism supports
both
confidentiality and authentication requirements.
(reference to standards documentation)

Supporting Metadata:
  - Transport security(none, HTTP over SSL/TLS; others as identified)
             o SSL/TLS has an additional attribute:
                           - SSL/TLS (no certificate), or
                                       - SSL/TLS with client certificate

Question:
- SSL/TLS sits a couple layers below WSRP in the protocol stack.  Maximum
interoperability will be achieved by using SOAP/HTTP/(SSL/TLS).   What
protocol binding is required in the service metadata to indicate the use of
HTTP/(SSL/TLS) stack beneath the SOAP layer?


Question:  should both parties(portal and portlet) have a say in the
transport mechanism used?  Or does the service simply declare how the
portal
should talk to it and from there the portal is required to conform to that
requirement?

Question:
- Should metadata support an 'supported but optional' scenario(versus
supported/required)  for secure transport?

Question:
- Should transport security be scoped to all portal/portlet exchanges(from
bind step through remaining registration lifecycle), or does WSRP need to
support more fine-grained selection of transport security?




Number             Type        Description             Comment
R402         MUST        The specification must support the ability for a
portlet to
authenticate a portal.
A portlet service may authenticate service requests from portals, but is
not
required to do so.   Transport or document-based approaches may be used for
authentication.

Applicable standards for transport-based authentication that are widely in
use are:
  - http/basic
  - client certificate  in conjunction with SSL/TLS.
 (reference standards documentation for these)

XML-Signature is the primary document-based mechanism to consider for
authenticating a service request.
(reference to the w3c xmldsig documentation)

Supporting metadata:
  - Authentication method(none, http/basic, SSL/TLS certificate, signature;
add others as required)

Issue:  there are no metadata standards for describing signature
mechanisms;
signatures themselves as defined by XML-Signature carry a number of
elements
describing how they are computed/validated(canonicalization method, digest
method, transforms, key information).  Should we replicate these elements
from XML-Signature in the portlet's metadata in order to describe how a
portal should sign a service request?

Issue:  what are the elements in the service request that should be signed?









----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>