Hi Rob, What you describe is really interesting from a general SCA perspective. There is an SCA Policy specification which describes something called Intents. These are labels describing Quality of Service requirements. Example are things like "integrity" (typically equates to signing), "confidentiality" (typically equates to encryption) and "authentication". How these intents are implemented is often binding specific, so the runtime needs to be configured with information that says how the intent is implementation for each binding. This is done using policies (typically WS-Policy). The following is one such example for configuring "confidentiality" for soap (encrypting the body):
<?xml version="1.0" encoding="UTF-8"?> <policySet name="SecurePolicy" provides="confidentiality" appliesTo="sca:binding.soap" xmlns="http://www.osoa.org/xmlns/sca/ 1.0" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; xmlns:wssp="http://www.bea.com/wls90/security/policy";> <wsp:Policy> <wssp:Confidentiality> <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"; /> <wssp:Target> <wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"; /> <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";> wsp:Body() </wssp:MessageParts> </wssp:Target> <wssp:KeyInfo /> </wssp:Confidentiality> </wsp:Policy> </policySet> So the service definition which would use this might look like /** * @service * @binding.soap * @requires confidentiality * */ Is this the sort of thing you were thinking of, or have I completely lost the plot? :-D Graham. On 11 Dec, 10:14, Rob <[EMAIL PROTECTED]> wrote: > Hi Graham, > > On 10 Dec, 10:25, Graham Charters <[EMAIL PROTECTED]> wrote: > > > Disclaimer: I've never done this... > > > Looking at the docs for the Soap Extension it seems you need to > > specify two entries in the "options" on the soap client constructor. > > These could be added as annotations that the binding understands: > > > /** > > * @reference > > * @binding.soap > > * @local_cert <location of the certificate> > > * @passphrase <the passphrase> > > */ > > public $the_secure_service; > > > Extensions I made to support the ebaysoap binding mean that these > > values would get passed through to the soap binding, so we could > > extend the soap support to pass them through to the SoapClient. We > > could do this for all the extra configuration of the soap client. The > > down side would be that these annotation names would be determined by > > the soap client, and might not be as we would like. > > > A slightly different approach would be to use an ini file, as is done > > by the ebaysoap support (actually, it supports both). We could just > > read all the name value pairs out of the ini, validate them and put > > them into the SoapClient. Ebaysoap does this and then uses the > > annotations as a way to override the values in the ini. > > > Unfortuantely, I don't have the time at the moment to do this, but if > > anyone is interested, the ebaysoap binding code would be a good place > > to start. > > I have been thinking about this for a long time with respect to > security but the issue seems to be broader than that. > The first option is not really good imo. There are a lot of options > and it also means it is SOAP specific. Using ini files is flexible, > but also not ideal (for the simple fact that you need an ini file). > > What about the possibility of being able to set specific containers > within SCA? I started thinking along this line when thinking about how > to apply WS-* or even authentication for REST and thought of some sort > of policy bucket. Either an array or object is passed to a static > method of SCA and set as a static variable. An annotation could > possibly be used indicating that it had policy which causes SCA to > grab and use the data that was set. This allows it to be flexible > where additional buckets/annoatiation flags can be added so that it is > not specific to just the use case I mention here. > > i.e. > > $policy = array('local_cert'=>'/usr/...', 'passphrase'=>'123'); > SCA::setPolicy($policy); > > /** > * @reference > * @binding.soap > * @policy True // or some other indicator (maybe policy name if > multiple policies are allowed) > */ > > The same idea could be used to provide different information for > different bindings. Instead of being so generic could also make the > annotation @security and pass a security object instead. Just ideas I > thought I'd toss out. > > Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
