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/
        URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"; />
          URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"; />
      <wssp:KeyInfo />

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


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 

Reply via email to