At this point I think we no longer have anything to say in the
specification -- this level of interoperability would seem to be the
domain of the WS-security folk. Choices for interoperability at our
level seems to be a business decision and nothing else -- hence I am
not sure if/why we should concern ourselves with it anymore.
-Mike-
Rich Thompson wrote:
I agree with the various comments
that
the proposed statement is insufficient on its own. It is an attempt to
establish a default with appropriate outs for when that default would
not
apply. It does not mandate that the Producer view the assertion as
trustworthy.
I think a discussion of trust should be added, perhaps with a caution
that
Producers not accept a user identity assertion without first
establishing
appropriate trust.
We may also want to add commentary
calling
attention to potential exposure that could happen if a user identity is
sent across the Internet in the clear. Whether or not this expands into
a broader discussion of reasonable Consumer policies that could
prohibit
the sending of the user identity to a particular Producer/portlet.
What I want to be careful about is
to
not define a policy language. While that certainly would be helpful, it
is happening (albeit slowly) in the broader community and definitely
falls
outside of the TC charter's definition of our work.
Rich
Richard
Jacob <>
03/08/06 12:29 PM
To
Rich
Thompson/Watson/IBM@IBMUS
cc
Subject
Re:
[wsrp-interfaces] Groups - SecurityQuestions.xls
uploaded
I'm not sure if the statement is really helps
being
interoperable and
secure.
I have the following concerns here:
1. we seem to try to use the username token (without PW) assertion to
establish a security context (e.g. jaas subject) on the producer side.
However I think we really miss trust here.
Having producer administrators to enable such a facility really
indicates/make them believe to them that they can enable a secure
environment. However this is not true. Without a trust establishment
there
is no security, every caller could establish an arbitrary security
context
as soon as she knows the userid to provide (not a big deal).
So the producer admin would need to take counter measures and configure
their servers with a trust requirement (but whichever method). But once
they enable it, the solution is not interoperable any more.
I would expect most server admin to want to have a real secure
environment
and not allow unknown parties to establish a security context as simple
as
that.
Therefor I would strongly recommend us to have a userId assertion with
trust only. Of course there are multiple options to enable such trust.
But
I think in most of the options the Producer needs to tell/agree with the
Consumer.
options I see:
- no trust: Producer knows what it does. I would consider this simply
insecure but doable for some environment. However, I would not consider
this being the default profile.
- network level: simple network separation, Producer only accepts
request
from certain hosts (close to social trust ;-) ), transparent to the
consumer, so from the consumer perspective the same profile as the
above.
- transport level: use SSL client certs
- SOAP level1: have two tokens, one for idAssertion (username only), one
for the trust identity (username/PW)
- SOAP level2: sign the assertion token/complete message etc.
- SOAP level3: encrypt the assertion token value (shared secret between
the
consumer and producer)
- ...
2. I think we should also have a 'no security/no id assertion' option.
The proposal seems to prevent this. Typically the security token for an
assertion is send with the SOAP mustUnderstand attribute - need to
check
if
the spec or WS-I BSP requires it.
So a sending Consumer with the token set would fail against a Producer
which doesn't require the token, simply because typically the web
service
stack would fail saying that it doesn't understand the token (bacause
it
is
not configured to do so), but it assumes it has to. So technically we
seem
to fail here.
3. another simple means would be to have a Username/PW token providing
the
login information for the consumer. This however seems to open the can
of
worms of identity federation, obtaining accounts for the users from the
Producer etc.
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:
Rich Thompson
<
m>
To
03/02/06 08:33 PM
g
cc
Subject
Re: [wsrp-interfaces]
Groups -
SecurityQuestions.xls
uploaded
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
-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
-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
