Authtentication and authorization are complex subjects, and there is no 'single solution' that fits all situations.
To decide on the best setup for your needs you should start with the following questions:
- will there be a single webservice consumer application or does the system have multiple different users?
- is there need for https, eg. do the webservices transfer sensitive data over public networks (internet)?
- is there any need for integrating user authentication with pre-existing solutions (eg windows active directory / ldap)?
1) For the 'very simple case', e.g. one single webservice-consumer-application, that has full access to every web service, you can very quickly and easily use the authentication provided by your web server, be it either Apache or IIS (look at the appropriate documentation).
If you need to give different access rights to different web services, you could put up many server.php pages, each serving some xmlrpc method, and assign different access rights to those (in fact you could put the business logic used by the webservices in functions/classes in separate php scripts, and simply include the scripts with the business logic from within the php scripts that expose the web services. this makes for a very clean architecture).
You need to make sure that the xmlrpc client you are using has support for the kind of HTTP authentication you are setting up.
If you are using phpxmlrpc as web service consumer, the client has support for http Basic auth, and for https when CURL is enabled. With recent php and curl versions, you might also get support for NTLM authentication, but I never tried it out...
Otoh you might 2) use php sessions for enabling authentication, or 3) use some home-brewed method that puts the authorization token inside the xmlrpc calls themselves.
Both options can turn out to be quite complex in implementation in the real world, even though they offer greater flexibility over web-server authentication.
If you use php sessions, you need to enable the session stuff in your server.php file, but must take care that it does not interfere too much with the http handling that is carried out by the library itself.
The xmlrpc client must also support using cookies, which many libraries do not do.
If you use the phpxmlrpc library as client, you should e.g. extract by hand the cookie from the first xmlrpc response received, and use it adding it by hand into successive requests.
If you use inside-the-webservice auth, the scheme would look something like this:
- app calls webservice 1, passing crdentials. webserver validates credentials, generates token, saves it into local db/session storage, and send it to client as response
- app receives token, and uses it as first (last?) parameter for every successive xmlrpc request
- all webservices (except the authenticating one) on the server must check for the presence of a valid token as first parameter
- you should add a close-seeion webservice for extra security, and take into account basic attacks such as session-injection and fixation, incase you have to guarantee real security
disclaimer: I am not a security consultant
Gaetano Giunta
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jem Mawson
Sent: Monday, March 27, 2006 3:38 AM
Subject: [phpxmlrpc] User authentication


I'm very new to PHP, taking it up primarily to use the XML-RPC package.

I would like to protect most of my rpc methods such that they will only execute when called by an authorised user. I'm not quite sure how to go about authentication though.

Does anybody have a best practices guide on how to achieve client authentication? Is it best to use http basic auth and check credentials on each method call? Or is there some inherent PHP support for sessions that can be used?

Yours confusedly,

phpxmlrpc mailing list

Reply via email to