OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Answers to Security Profile questions


Answers below.

Regards,
Subbu

-----------------------------------------------------------------------------

Considering the number of customer requests for interoperable security 
profiles and the lack of a standardized policy framework for negotiating 
a security profile to use for WSRP-related messages, the WSRP TC is 
seeking input about whether simple interim, interoperable profiles could 
be defined for the use case of multiple vendor's implementations being 
deployed within a single security domain in the mid-2006 timeframe.

1. The WSRP use case involves an intermediary (the WSRP Consumer) acting 
on behalf of an End-User when interacting with the web service provider 
(the WSRP Producer). As a result, there is an interest in transferring 
the identities of both the WSRP Consumer and the End-User to the WSRP 
Producer. This results in several questions:
1.a. Do you support the receipt of multiple identities (Consumer and 
End-User) on a SOAP message which can be separately queried by the 
provider application? Do you support sending multiple identities?

<subbu>
No. We propagate user identity via a security header, and rely on 
out-of-band setup for consumer trust.
</subbu>

1.b. What WS-Security tokens will be supported for transferring 
identities (e.g. UserName, SAML, Kerberos, Digital Signature, etc)?

<subbu>
UserName and SAML tokens.
</subbu>

1.c. Would transferring the End-User identity via a WS-Security token 
and the Consumer identity via transport-level security be supported?

<subbu>
Not explicitly. See answer to 1.a above.
</subbu>

1.d. Any restrictions on how multiple identities can be attached to a 
particular SOAP message?a token.

<subbu>
No restrictions on the sending side, but such messages may not be 
supported by the producer.
</subbu>

2. What security granularity is expected when transferring an identity 
(for example; portals often have a concept of user role that relates to 
the End-User's current use of the portal rather than their identity ... 
is the transfer of such attributes supported (e.g. via SAML attributes))?

<subbu>
Role information is not propagated via attributes.
</subbu>

3. Is support for maintaining security contexts for multiple web service 
requests anticipated? If so, using what security technology (e.g. 
WS-SecureConversation)?

<subbu>
We are exploring this possibility.
</subbu>

4. Is automated configuration of all endpoints supported? If so, how are 
any particular inputs to the process indicated, supported, standardized 
and maintained?

<subbu>
The producer would expose its policy attached to the WSDL. The policy 
would describe security tokens required by the producer. But further 
configuration will be required by the consumer to be able to send 
messages that the producer can process.
</subbu>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]