[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Groups - SecurityQuestions.xls uploaded
Hi Mike,
a) we don't require that an assertion has to be used with a trust
establishment on a technical level.
However this is something we don't want to recommend to our customer since
this really opens security holes. So the prereq is more at a guideline
level.
On the trust support we could do:
- username token for assertion & username/password token for trust id
(similar to basic auth). The tokens are distinguished by the fact that the
assertion has no PW but the trust ID has. First trust is checked, i.e.
username/PW verified, then establish the security context based on the
asserted userid
- sign the assertion token or the body. Supported algorithms are:
Digest: SHA1 http://www.w3.org/2000/09/xmldsig#sha1
MAC: HMAC-SHA1 http://www.w3.org/2000/09/xmldsig#hmac-sha1
Signature: DSA with SHA1 http://www.w3.org/2000/09/xmldsig#dsa-sha1, RSA
with SHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1
Canonicalization: Canonical XML (with comments)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments, Canonical XML
(without comments) http://www.w3.org/TR/2001/REC-xml-c14n-20010315,
Exclusive XML canonicalization (with comments)
http://www.w3.org/2001/10/xml-exc-c14n#WithComments, Exclusive XML
canonicalization (without comments) http://www.w3.org/2001/10/xml-exc-c14n#
Transform: STR transform
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0
#STR-Transform
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-
security-1.0#STR-Transform, XPath
http://www.w3.org/TR/1999/REC-xpath-19991116, Enveloped signature
http://www.w3.org/2000/09/xmldsig#enveloped-signature, XPath Filter2
http://www.w3.org/2002/06/xmldsig-filter2, Decryption transform
http://www.w3.org/2002/07/decrypt#XML
I haven't verified the support yet with WSRP but am confident that it works
;-)
- SSL with client certificates as the trust model
b) the absence of PW
It would be also very interesting to see what others support here and if we
have a common ground.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Michael Freedman
<michael.freedman
@oracle.com> To
wsrp-interfaces@lists.oasis-open.or
03/08/06 05:54 PM g
cc
Subject
Re: [wsrp-interfaces] Groups -
SecurityQuestions.xls uploaded
After talkign with my security guys some more we may need to dig deeper to
see if we really have interoperability at this level. Can folks
investigate/answer:
a) does the producer require/expect establishing consumer trust via
WS-Security techniques as a prerequisite for using the UserName without
password identity? If so what techniques does it support [signing the
username token and using the signature as the trust model]? Please expand
on the details -- for example which digital signature technologies does it
support?
b) How does the receiver implement Username without password? I.e. is
it merely the absence of the password field that indicates no password or
is the password field sent with a value that signifies its empty [if so
what is the value]? Something else?
-Mike-
Rich Thompson wrote:
I agreed to provide a summarizing email proposing how we move forward
after the initial discussion on this issue on the Interfaces SC call.
The base level goal is to define an interoperable means for
propagating the user's identity to the Producer. Other possible goals
(e.g. Consumer identity, metadata about supported/required
protocols/tokens/algorithms, etc) haven't achieved either as broad a
consensus on their need or feasibility to address on this first pass.
I would encourage those with a definitive proposal regarding such
goals to start an email thread around their goal and proposal once
the discussion around this base one draws toward a conclusion.
The clear thing from the answers we received is that the UserName
token is broadly supported. At the minimum, we can encourage it to be
the default means for transferring the user's identity. Therefore, I
propose adding the following to the first paragraph of 11.2:
As the UserName token, defined by WS-Security, appears to have the
broadest implementation support, it is RECOMMENDED that Consumers use
the UserName token to transfer the user's identity to the Producer
unless either policy prevents the Consumer from making such a
transfer or a different means has been mutually configured for
transferring the user's identity to the Producer.
Comments?
Rich
Rich
Thompson/Watson/IBM@IBMUS
To
02/22/06 11:54 AM wsrp-interfaces@lists.oasis-open.
org
cc
Subject
Re: [wsrp-interfaces] Groups -
SecurityQuestions.xls uploaded
Here is the promised spreadsheet summarizing the answers received. At
a high level, there appear to be two ways to transfer multiple IDs
which multiple companies support:
1. User ID via WSS token; Consumer ID via SSL/TLS
2. User ID via WSS token; Consumer ID via digital signature
Also, # companies supporting a particular WSS token (out of 6 answers
received):
6 - UserName
4 - SAML (did everyone mean the explicit "sendvouches" Mike referred
to?)
3 - Digital Signature
2 - UserName/PW
1 - Liberty
Hopefully this provides a little fodder for thought ahead of the
Interfaces SC call to discuss next steps.
Rich
Rich
Thompson/Watson/IBM@IBMUS
To
02/22/06 11:40 AM wsrp-interfaces@lists.oasis-open
.org
cc
Subject
[wsrp-interfaces] Groups -
SecurityQuestions.xls uploaded
The document named SecurityQuestions.xls has been submitted by Rich
Thompson to the WSRP Interfaces SC document repository.
Document Description:
Summaries extracted from answers to security questions.
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=16838
Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/16838/SecurityQuestions.xls
PLEASE NOTE: If the above links do not work for you, your email
application
may be breaking the link into two pieces. You may be able to copy
and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]