<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006>Authtentication and authorization are complex subjects,
and there is no 'single solution' that fits all situations.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>To
decide on the best setup for your needs you should start with the following
questions:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006>- will there be a single webservice consumer
application or does the system have multiple different
users?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- is
there need for https, eg. do the webservices transfer sensitive data over public
networks (internet)?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- is
there any need for integrating user authentication with pre-existing solutions
(eg windows active directory / ldap)?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>You
need to make sure that the xmlrpc client you are using has support for the kind
of HTTP authentication you are setting up.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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...</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>The
xmlrpc client must also support using cookies, which many libraries do not
do.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>If you
use inside-the-webservice auth, the scheme would look something like
this:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- 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</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- app
receives token, and uses it as first (last?) parameter for every successive
xmlrpc request</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- all
webservices (except the authenticating one) on the server must check for the
presence of a valid token as first parameter</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=240344409-27032006>- 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</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006>disclaimer: I am not a security
consultant</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006>Bye</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006>Gaetano Giunta</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=240344409-27032006></SPAN></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B>
phpxmlrpc-bounces@lists.usefulinc.com
[mailto:phpxmlrpc-bounces@lists.usefulinc.com]<B>On Behalf Of </B>Jem
Mawson<BR><B>Sent:</B> Monday, March 27, 2006 3:38 AM<BR><B>To:</B>
phpxmlrpc@lists.usefulinc.com<BR><B>Subject:</B> [phpxmlrpc] User
authentication<BR><BR></FONT></DIV>Hello<BR><BR>I'm very new to PHP, taking it
up primarily to use the XML-RPC package.<BR><BR>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.
<BR><BR>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? <BR><BR>Yours confusedly,<BR>Jem<BR clear=all><BR>-- <BR><A
href="http://www.loftinspace.com.au/jem">http://www.loftinspace.com.au/jem</A>
</BLOCKQUOTE></BODY></HTML>