[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Groups - SecurityQuestions.xls uploaded
agreed, I'm not interested in developing a policy language at all.
I merely tried to propose "security profiles" that contain both id
assertion and trust. I also mentioned that there are possible ways to
establish trust, some of them may be completely transparent to the consumer
if they happen for example on the network layer.
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
Rich Thompson
<richt2@us.ibm.co
m> To
wsrp-interfaces@lists.oasis-open.or
03/08/06 10:33 PM g
cc
Subject
Re: [wsrp-interfaces] Groups -
SecurityQuestions.xls uploaded
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
<richard.jacob@de.ibm.com>
To
03/08/06 12:29 PM Rich Thompson/Watson/IBM@IBMUS
cc
wsrp-interfaces@lists.oasis-ope
n.org
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:richard.jacob@de.ibm.com
Rich Thompson
<richt2@us.ibm.co
m> To
wsrp-interfaces@lists.oasis-open.or
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 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]