Picking up on the question of what the developer should see: a little bit of this is already visible in the SCA Java Annotations spec.
As you probably know, there is a generalised Policy spec for SCA, that describes how policies should be referred to in the XML definitions. It is intended to be a layer of abstraction one up from any implementation e.g. WS_Security. It has the notion of "intents". The two areas where it is most worked out are are security and reliability. There are three intents for security: authentication, confidentiality, and integrity. The idea of making policies one step up in abstraction is that if the XML defining the service says you want authentication, and you are using a web service binding, you will use WS_Security: if you are using JMS then you will use what is appropriate there, and so on. The Java Annotations spec takes the three security intents just that one little bit further and says, for security, you can have the intent as an annotation: e.g. you put @Authentication in the Java component. I imagine that since SCA for PHP is already keen on annotations, we would want the developer to have exactly the same: in the component they just put @Authentication or @Confidential or @Integrity, and we do the rest. Of course we realise there has to be some registry of passwords or certifications behind the scenes but from the developer point of view that would be hidden - no nuts, no bolts. That's the only way you can reliably keep the specifics of bindings out of the business logic. On Mar 7, 10:42 am, [EMAIL PROTECTED] wrote: > On 6 Mar, 19:57, "Rob" <[EMAIL PROTECTED]> wrote: > > > > > On 6 Mar, 14:03, [EMAIL PROTECTED] wrote: > > > > On 6 Mar, 16:40, "jon" <[EMAIL PROTECTED]> wrote: > > > > Any thoughts on these issues at large? Does anybody have any resources > > > > they know of that address WS-* PHP implementation? I am interested in > > > > starting a discussion about these issues, and of course this may be > > > > the wrong venue, but please contact me if you are interested in > > > > talking about this, or if any of the PHP SOA team members have > > > > thoughts as well. > > > Jon, > > > For now, you can use the code I have written for WS-Security and WS- > > Addressing (find it athttp://www.cdatazone.org/inthe code section). > > I am still working on the XML Encryption though I do have it working > > from the soap client right now (not yet released code). > > The stuff has been tested against many different SOAP implementations > > such as .NET and a few different Java servers. > > > > It would be really good to bring this policy idea into our PHP > > > implementation somehow. I.e. simply allow developers to say that they > > > want a binding to be secure or reliable or transactional. I'm afraid > > > we haven't started this to date. As with everything it's a matter of > > > time. > > > Simon, I dont know how easy this really would be. I too have been > > thinking about this lately (strictly in respect to SOAP as I'm not > > sure if you are thinking about more binding types). For example, SCA > > leverages ext/soap right now. As you may see from the work I have done > > with some of the WS-* stack on ext/soap, its not a simple plug and > > play. Also, in regards to the SOAP header, many of these cant simply > > be done with the ext/soap header support. Take XML DSig (this is the > > most used WS-Security feature people using my stuff use). The entire > > SOAP envelope needs to have been constructed in order to generate the > > signature in many cases. > > > If the axis2 stuff is ever released and proves itself, maybe down the > > road it could be leveraged (they claim to do everything), but until > > then you would need to do similar functionality to what I do now. > > > Rob > > Hi Rob > > Agreed, its not easy. Most of the existing infrastructure has not been > designed to make this kind of thing easy. This is not restricted to > PHP I have to say. I guess I separate the problem in two in my mind. > > Firstly the ability implement security, tansactionality etc. behaviour > over a particular protocol. Some platforms are better than others at > this, eg, in Java SCA they are using Axis2 for WS support and this has > the Rampart WS security implementation (although it's not used at > present in SCA as no security/policy work has been done there either!) > so maybe this will work out in PHP too as you say. I think we do need > to start getting our story straight though in PHP SCA so need to build > some experience of what is going to be required. Having your code will > be a great help so will take a look when time allows. Thanks for the > pointer. > > Secondly the ability to develop some sensible way to easily describe > what is required for the developer, i.e. I want a particular reference > to be signed, encrypted, authenticated, without them having to get too > deeply into the nuts and bolts of the implementation apart from > providing credentials etc. Granted doing this in some protocol > independent way sounds like a holy grail task to me but it at least if > we can go some way to hiding all the API schenanigans for an > indiviudual protocol, eg, ws, then this will give us some idea of how > viable the policy based approach is. > > Regards > > Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
