Hi Rob, I like your ideas very much. The only thing I would like to see is something at the annotation level which could be related to the broader SCA (i.e. the Intents). I think this would then give us the flexibility to specify some QoS requirements and then have it configured via the associative array approach or the SCA policySet approach.
So, perhaps an annotation might look like: /** * @reference * @binding.soap * @requires authentication * */ We could then specify a policy array that defines what "authentication" means for the soap binding. Maybe something like: $policy = array('soap'=>array('authentication'=>array('local_cert'=>..., 'passphrase'=>...))); The actual intents can be named whatever the developer likes, although the SCA specs do define the meaning of a small set. I'm not sure where the developer would provide the options, and that may also affect flexibility - ie. would all uses of soap have to share the same configuration? Does something like this make sense? Regards, Graham. Rob wrote: > Hi Graham, > > I was trying to stay away form the WS-Policy/SecurityPolicy words :). > That is in-line with my thoughts, but think (at least to start off) > that something simpler should be implemented. > The WS-* tends to be a bit complicated for developers and PHP is meant > to be simple. That doesn't mean looking at the SCA Policy > implementation is out of the question, just something that probably > should be held off until at least there is some simple mechanism in > place that should be able to handle many of the common cases. This is > where I was going with the: > $policy = array('local_cert'=>'/usr/...', 'passphrase'=>'123'); > SCA::setPolicy($policy); > > /** > * @service > * @binding.soap > * @options True > */ > > If options is true then the service would check and use any options > that were set via the setPolicy (or whatever name given) method. It > might also be good to make them binding specific, so the array would > be something like: > $policy = array('soap'=>array('local_cert'=>..., 'passphrase'=>...)); > so that options for multiple bindings can be set and leveraged. > > Similar functionality could also be used for the confidentiality > example you had laid out. *HOWEVER*, this would not be as flexbile as > dealing with WS-Policy/SecurityPolicy and be limited to specific > functionality. (i.e. if signing a document, you can specify body, > headers, but not target specific subsets). > An implementation like this should solve at least 80%-90% of the use > cases and still be simple enough for the average developer to use > without having to learn all the WS-* intricacies. > > Another example: adding username token - implementation really > dependant upon wether this would be its own annotation or if a single > annotation is used and they are grouped by binding. > i.e structure: > array(bindingname=>array(optionname=>array(options))); > bindingname - binding that uses the options (maps to the > @binding.bindingname annotation) > optionname - something that SCA understands and uses that to set the > options for > options - name/value pairs that SCA uses within the context of > optionname > > exmaple: > > $token = array('soap'=>array('usernametoken'=>array('username'=>'rob', > 'password'=>'123456'))); > SCA::setPolicy($token); > > this would mean that for the soap binding, send a username token with > the username/password combination. > re-writing my origional case: > $policy = array('soap'=>array('options'=>array('local_cert'=>..., > 'passphrase'=>...))); > for the soap binding, set the soap constructor options with the > following name/value pairs.. > > Now going forward after something like the above is implemented, > depending upon need, then something more robust can be implemented, > although might not really be needed just for the sake of the few who > might actually have use for rich policies. > > What do you think about something along those lines? I know there are > details that would need to be hashed out, but this is the basic idea > of how I could see it working without getting overly complex. > > Rob > > On 11 Dec, 16:16, Graham Charters <[EMAIL PROTECTED]> wrote: > > 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 firstname.lastname@example.org 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 -~----------~----~----~----~------~----~------~--~---