Re: How to access HTTPS Webservice

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_cer
t'=>...,
'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...googlemail.com> 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/xm
lns/sca/
> > 1.0"
> >   xmlns:wsp="ht
tp://schemas.xmlsoap.org/ws/2004/09/policy"
> >   xmlns:wssp="ht
tp://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...ctindustries.net> wrote:
> >
> > > Hi Graham,
> >
> > > On 10 Dec, 10:25, Graham Charters
<gchart...googlemail.com> 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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Graham,

On 19 Dec, 06:47, Graham Charters <gchart...googlemail.com> 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_cer
t'=>...,
> '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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---