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
Bye
Gaetano Giunta
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Jem
MawsonSent: Monday, March 27, 2006 3:38 AMTo:
phpxmlrpc@lists.usefulinc.comSubject: [phpxmlrpc] User
authenticationHelloI'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,Jem-- http://www.loftinspace.com.au/jem
___
phpxmlrpc mailing list
phpxmlrpc@lists.usefulinc.com
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
