How to access HTTPS Webservice

Hello NG,

I am pretty new to SCA (I read about it in PHP-Magazin thie year and
want
to use it in my project).
What i want to do is, to access a SOAP Service, hosteted on a SSL-
protected
Server, which requires a client certificate?

Is there a chance or will I have to use SoapClient instead I found no
information about it on the homepage? Will I have to create an own
binding?

The easiest thing would be, to extend Class "SCA_Bindings_soap_Proxy"
with the functionality
to give the SoapClient user defined options.

Thanks for your answers in advance
Stefan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[monxton]

stefan.kuhn@... wrote:

> Hello NG,
>
> I am pretty new to SCA (I read about it in PHP-Magazin thie year and
> want
> to use it in my project).
> What i want to do is, to access a SOAP Service, hosteted on a SSL-
> protected
> Server, which requires a client certificate?
>
> Is there a chance or will I have to use SoapClient instead I found no
> information about it on the homepage? Will I have to create an own
> binding?
>
> The easiest thing would be, to extend Class "SCA_Bindings_soap_Proxy"
> with the functionality
> to give the SoapClient user defined options.

Stefan, I also needed to do this a while back, actually while using the
Atompub binding rather than soap - see
http://thread.gmane.org/gmane.comp.php.sca-sdo/434/focus=455. So in this
case I'm afraid I just hacked the binding, as noted in the referenced
article, but the good news is that it did work for me.

For soap it's a bit different under the covers, as you say, because SCA
would need to exploit the behaviour of the SoapClient rather than use
cURL, but I'd hope that  a common annotation could be devised. I know
this has been discussed in the past - is there anyone working on it?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters-2]

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.

Graham.

On 6 Dec, 17:06, Caroline Maynard <c...@...> wrote:

> stefan.k...@... wrote:
> > Hello NG,
>
> > I am pretty new to SCA (I read about it in PHP-Magazin thie year and
> > want
> > to use it in my project).
> > What i want to do is, to access a SOAP Service, hosteted on a SSL-
> > protected
> > Server, which requires a client certificate?
>
> > Is there a chance or will I have to use SoapClient instead I found no
> > information about it on the homepage? Will I have to create an own
> > binding?
>
> > The easiest thing would be, to extend Class "SCA_Bindings_soap_Proxy"
> > with the functionality
> > to give the SoapClient user defined options.
>
> Stefan, I also needed to do this a while back, actually while using the
> Atompub binding rather than soap - seehttp://thread.gmane.org/gmane.comp.php.sca-sdo/434/focus=455. So in this
> case I'm afraid I just hacked the binding, as noted in the referenced
> article, but the good news is that it did work for me.
>
> For soap it's a bit different under the covers, as you say, because SCA
> would need to exploit the behaviour of the SoapClient rather than use
> cURL, but I'd hope that  a common annotation could be devised. I know
> this has been discussed in the past - is there anyone working on it?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Richards]

Hi Graham,

On 10 Dec, 10:25, Graham Charters <gchart...@...> 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@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters-2]

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 <rricha...@...> wrote:

> Hi Graham,
>
> On 10 Dec, 10:25, Graham Charters <gchart...@...> 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@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Richards]

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 <gchart...@...> 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 <rricha...@...> wrote:
>
> > Hi Graham,
>
> > On 10 Dec, 10:25, Graham Charters <gchart...@...> 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@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters-2]

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 <gchart...@...> 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 <rricha...@...> wrote:
> >
> > > Hi Graham,
> >
> > > On 10 Dec, 10:25, Graham Charters <gchart...@...> 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@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Rob Richards-3]

Hey Graham,

On 19 Dec, 06:47, Graham Charters <gchart...@...> wrote:

> 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?

Yes this does, but before worrying about the annotations which would
be on the server side of things, I think implementing something for
the client first would be the quickest way to provide a good amount of
functionality, while also demonstrating how it would work for the more
advanced things. Before thinking about all the questions you raised,
read my entire reply first. I answered the flexibility one at the end
as the examples I provided here hopefully lead to that answer.

I took the helloWorld SCA example from pecl. Now, say I needed to pass
a local cert and its passphrase so that the client can authenticate.
Here because this really isnt a specific intent other than I want to
send some SoapClient options, I would write it as:

include 'SCA/SCA.php';

$policy = array('soap'=>array('options'=>array('local_cert'=>...,
'passphrase'=>...)));

SCA::setPolicy($policy);

$greeting_service  = SCA::getService('./wsdl/Greeting.wsdl');

/* For the following, the binding checks if any policies are set for
it.
Here it finds options, so the options are passed to the SoapClient
constructor. */
$greeting          = $greeting_service->greet($name);


I called it "options" because thats what they are. Options for the
constructor.
This implementation would be the basis for future policies/intents,
such as authentication (which may possibly include the loca_cert stuff
from the above or limited to just WS-Security, etc..)

Going forward, saw we wanted to implement authentication on the
server.
These policies are not for every Soap server we have, just for this
particular one. By particular one I consider any class we use a
particular one.
If the developer wants different policies for the different methods,
then he makes different classes. I dont see why any logical grouping
of methods using the same binding would require different options.
Different options to me would mean that the methods do not belong
grouped together as they serve different unrelated purposed.
Anyways.... the code would look like:

include 'SCA/SCA.php';

$policy = array('soap' =>
                  array('authentication' => array(
                                  'type' => 'usertoken',
                                  'methodname' => 'validation');

SCA::setPolicy($policy);

/**
 * @service
 * @binding.soap
 * @requires authentication
 */
class Greeting
{
    private function validation($username, $password) {
        return true;
    }

    /**
      * @param string $name
      * @return string
      */
    public function greet($name)
    {
        return 'hello ' . $name;
    }
}

The server would call the validation method with the username/password
and act upon the return value.

Then on the client side:

include 'SCA/SCA.php';

$policy = array('soap' =>
                  array('authentication' => array(
                                  'type' => 'usertoken',
                                  'username' => 'rob',
                                  'password' => '123456',
                                  'digest' => false);

SCA::setPolicy($policy);

$greeting_service  = SCA::getService('./wsdl/Greeting.wsdl');

/* For the following, the binding checks if any policies are set for
it.
Here it finds authentication. It sees it is usertoken type, so creates
the WS-Security usertoken with the supplied username and password and
does not use password digest. */
$greeting          = $greeting_service->greet($name);


Because there are no annotations on the client side, the client always
checks if there are any policies set and processes the ones it knows
how to process.
The flexibility lies with the options/policies being set on a per file
basis. Typically an endpoint utilizes the same authentication
mechanism for all of the exposed operations. The options/policies are
set as a static member of the SCA class, so would pertain only within
that scope. If different policies are desired, then the operations
should be separated out to their own endpoint. At least this is my
opinion on that.

DISCLAIMER: I'm also not saying lets jump right in and implement WS-*
or anything like that. I just used authentication as an example going
off of your post. Outside of the "options" policy, thought should be
given to what type of functionality would be most useful to the end
user (depends upon what binding type is used the most, what would it
benefit from the most, and is it doable) and then go from there rather
than just picking policies arbitrarily to implement.

Make note that the naming and structures I have used here are most
likely not optimal, nor are what I am suggesting. They were what came
to mind and allowed me to code these examples without too much
thought, but hopefully illustrate my point. Let me know if anything is
unclear?

Rob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa@...
To unsubscribe from this group, send email to phpsoa-unsubscribe@...
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---