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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx-comment message

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


Subject: support for policy changes at runtime?


Hello,
 
I am hoping that someone can set me straight about WS-Policy,
WS-SecurityPolicy, and WS-Trust..
 
WS-PolicyAttachment v1.2 discusses 2 ways for associating policy to a
web service, either by embedding or referencing the policy within the
WSDL specification, or by associating the policy with the UDDI
registration of the web service.
 
WS-PolicyFramework 1.2 provides <ExactlyOne> type semantics that
support policy alternatives but not conditionality.
 
Say I have a web service that enforces a security policy that requires
use of digital signatures but no encryption, but additional security
such as use of encryption is necessary when threat conditions change. 
 
If I embed or reference the security policy within the WSDL, would it
be necessary to re-generate or modify the source code in order to
change the security policy? Is there any context for changing a web
service's security policy on the fly, i.e., at run time??
 
WS-Trust 1.3 states that a soap envelope may be specified as a security
token for the validation binding. However, in my reading of this
specification it was not implied that arbitrary SOAP envelopes are not
considered security tokens in the general case. Is this correct? 
 
This relates to the previous questions in that if it is possible to
change a web service's security policy at run time, then can STS be
used as a trusted repository for security tokens consisting of SOAP
messages that contain the security policy dejour?
 
Thanks in advance for any input.
 
Jackson Wynn
jwynn@mitre.org


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