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