SCA services access control...?

[Yannick-18]

Hi,

I think I mentioned it the first time I sent an e-mail on this list,
but one of the major problems I have with using SCA is that, if I do
implement it into existing classes, I don't want just anyone to be
able to use them freely.

In Dokeos (and outside of any web services context), we rely on an
initial authentication process (using sessions) to make sure the user
is authorized to do what he is trying to do.

However, if I want to take the full benefit out of SCA, I would like
to be able to re-use my existing functions and *just* add a few
comments here and there, and be done with it. Now the problem is that,
if I do that, I inevitably loose the "session" context (as I am going
through web services), and so I loose the authentication pre-check.

This is a big problem to me, as adding an authentication process
specifically for the web services, it means I *have to* reimplement
most of my functions to add an authentication layer.

I remember Caroline saying that someone was remotely working on/
thinking about the topic, but haven't seen any discussion about it
since then.

How are other people here dealing with that?
This is most likely to be the dead-end for us in terms of either
adopting SCA_SDO or at least considering it as a real benefit.

From the top of my head, I would say that if there was a way to
configure a web service transparently to work in an "authenticated
mode" and that, from there on, it always added a required "first"
parameter being a shared key, and optionally identified the source by
IP address, it would be enough.

Something like adding a parameter @security.shared_key ../mykey.php in
the class documentation, that would automatically:
- generate a modified WSDL that shows a shared_key param as a first
parameter for any function
- add a check of this first parameter before going through with the
answer to the service request

What would be the likeliness of that idea to be integrated into
SCA_SDO? We have plans for a release of our next Dokeos version at the
end of September. If it is likely, then how likely would it be that a
modified version of SCA_SDO can be rolled into PECL by then (because,
of course, we want our users to be able to use the feature without
having to pack SCA_SDO in our package)? As SCA_SDO is not written in
PHP, it would be difficult to me to contribute code, but I can
certainly contribute ideas, analysis and testing.

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

[Yannick-18]

Anybody got anything to say about this?

On 27 juil, 20:11, Yannick <ywarn...@...> wrote:

> Hi,
>
> I think I mentioned it the first time I sent an e-mail on this list,
> but one of the major problems I have with using SCA is that, if I do
> implement it into existing classes, I don't want just anyone to be
> able to use them freely.
>
> In Dokeos (and outside of any web services context), we rely on an
> initial authentication process (using sessions) to make sure the user
> is authorized to do what he is trying to do.
>
> However, if I want to take the full benefit out of SCA, I would like
> to be able to re-use my existing functions and *just* add a few
> comments here and there, and be done with it. Now the problem is that,
> if I do that, I inevitably loose the "session" context (as I am going
> through web services), and so I loose the authentication pre-check.
>
> This is a big problem to me, as adding an authentication process
> specifically for the web services, it means I *have to* reimplement
> most of my functions to add an authentication layer.
>
> I remember Caroline saying that someone was remotely working on/
> thinking about the topic, but haven't seen any discussion about it
> since then.
>
> How are other people here dealing with that?
> This is most likely to be the dead-end for us in terms of either
> adopting SCA_SDO or at least considering it as a real benefit.
>
> From the top of my head, I would say that if there was a way to
> configure a web service transparently to work in an "authenticated
> mode" and that, from there on, it always added a required "first"
> parameter being a shared key, and optionally identified the source by
> IP address, it would be enough.
>
> Something like adding a parameter @security.shared_key ../mykey.php in
> the class documentation, that would automatically:
> - generate a modified WSDL that shows a shared_key param as a first
> parameter for any function
> - add a check of this first parameter before going through with the
> answer to the service request
>
> What would be the likeliness of that idea to be integrated into
> SCA_SDO? We have plans for a release of our next Dokeos version at the
> end of September. If it is likely, then how likely would it be that a
> modified version of SCA_SDO can be rolled into PECL by then (because,
> of course, we want our users to be able to use the feature without
> having to pack SCA_SDO in our package)? As SCA_SDO is not written in
> PHP, it would be difficult to me to contribute code, but I can
> certainly contribute ideas, analysis and testing.
>
> Yannick

--~--~---------~--~----~------------~-------~--~----~
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 Yannick, once again, apologies for not responding sooner.



Security is something which has come up on numerous occasions, but no
one has been able to find the time to incorporate something.  I
believe unless you are able to do something that, sadly, this is still
the case.  I've included a couple of links to previous discussions
[1,2].



I'm afraid don't fully appreciate the issues you are encountering, but
have some thoughts on the suggested design... I think modifying the
service interface to include security parameters does not seem like an
approach that fits with SCA.  SCA tries to keep service interfaces
clean (focus on business interface) and consistent across protocols.
I think the security information more appropriately belongs in a
header, rather than on the service interface.  I think using
annotations to control things is good, and if the configuration is
complex then an ini file approach like the ebaysoap binding can help
[3].



I hope this helps.



Regards, Graham



[1] http://groups.google.co.uk/group/phpsoa/browse_thread/thread/c92450e7a170a3e8/43f639a7b4f7af07?lnk=gst&q=Kieran#43f639a7b4f7af07



[2] http://groups.google.co.uk/group/phpsoa/browse_thread/thread/47d069e4ca44d9a9/aa11352d10c28e03?lnk=gst&q=Rob#aa11352d10c28e03



[3] http://osoa.org/display/PHP/eBay+SOAP+Binding+Documentation


On 30 Jul, 04:15, Yannick <ywarn...@...> wrote:

> Anybody got anything to say about this?
>
> On 27 juil, 20:11, Yannick <ywarn...@...> wrote:
>
> > Hi,
>
> > I think I mentioned it the first time I sent an e-mail on this list,
> > but one of the major problems I have with using SCA is that, if I do
> > implement it into existing classes, I don't want just anyone to be
> > able to use them freely.
>
> > In Dokeos (and outside of any web services context), we rely on an
> > initial authentication process (using sessions) to make sure the user
> > is authorized to do what he is trying to do.
>
> > However, if I want to take the full benefit out of SCA, I would like
> > to be able to re-use my existing functions and *just* add a few
> > comments here and there, and be done with it. Now the problem is that,
> > if I do that, I inevitably loose the "session" context (as I am going
> > through web services), and so I loose the authentication pre-check.
>
> > This is a big problem to me, as adding an authentication process
> > specifically for the web services, it means I *have to* reimplement
> > most of my functions to add an authentication layer.
>
> > I remember Caroline saying that someone was remotely working on/
> > thinking about the topic, but haven't seen any discussion about it
> > since then.
>
> > How are other people here dealing with that?
> > This is most likely to be the dead-end for us in terms of either
> > adopting SCA_SDO or at least considering it as a real benefit.
>
> > From the top of my head, I would say that if there was a way to
> > configure a web service transparently to work in an "authenticated
> > mode" and that, from there on, it always added a required "first"
> > parameter being a shared key, and optionally identified the source by
> > IP address, it would be enough.
>
> > Something like adding a parameter @security.shared_key ../mykey.php in
> > the class documentation, that would automatically:
> > - generate a modified WSDL that shows a shared_key param as a first
> > parameter for any function
> > - add a check of this first parameter before going through with the
> > answer to the service request
>
> > What would be the likeliness of that idea to be integrated into
> > SCA_SDO? We have plans for a release of our next Dokeos version at the
> > end of September. If it is likely, then how likely would it be that a
> > modified version of SCA_SDO can be rolled into PECL by then (because,
> > of course, we want our users to be able to use the feature without
> > having to pack SCA_SDO in our package)? As SCA_SDO is not written in
> > PHP, it would be difficult to me to contribute code, but I can
> > certainly contribute ideas, analysis and testing.
>
> > Yannick

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