Re: [Phplib-users] three tier auth made possible

[Giancarlo <gia...@na...>]

...
>   Secondly, your example would be addressed in two parts I would guess.  A
> auth_preauth function would be written that runs in start so that when you
> browsed to site A or B, the other was queried through an XMLRPC interface
> to see if you were already authenticated there, and if so, would give you
> the same level of access.  If you were not, then (assuming blocking and not
> default auth) if that failed it would show the login screen.

Well, I chose page.inc because it can act as the 'middle tier'. It can call 
the local auth, the one within its same class, or the remote.
There can be many cases: 
a) The simplest one is that Site A registers at Site B, and only Site B 
performs the authentication. In this case you could register to Site B 
directly, or by entering the info at Site A, but the authentication is done 
always by Site B.  It could make sense that Site A would pull down locally, 
and consolidate locally, some info for all his users that are registered at 
Site B, with some extra info pertaining only to his site activity.
b) A second case, that I see problematic, would be that one could either be 
registered at Site A or at Site B. In this case Site A would need to query 
Site B and vv, to see if the user is registered there, if not here.

So, for case a:
on Site A, page.inc is an  HTML page handler, checks GET/POST vars, calls  
its own auth that perform an XMLRPC call to Site B. 
On Site B the request is handled by an XML page.inc handler, which calls its 
local auth methods that rely on the local db, and this XML page.inc replies 
in XML data to Site A.

On Site B there can be also an HTML page.inc handler, that would manage local 
requests coming from their own site,, so all locally.

> auth_handlelogin would take the results returned from the login form, check
> it's local auth storage mechanism, check the other site through XMLRPC, and
> if either one was successful, return the uid.  All of this with no logic in
> page at all.
>   As far as cross site registration, propagating information from one DB to
> another is much better accomplished at the DB level.  Otherwise you end up

This openss up a series of problems as granting the access to the DB to the 
network. I see better an XML/SOAP/XXX interface for this. Dbs are commonly 
deeply buried on dedicated boxes inside firewalls.


All these things cannot be accomplished with a single method call, as 
$auth->start. We need to be able to ask some specific service to auth: 
authenticate/login/register. This does not mean that we won't need to be able 
to call a single method, but that makes sense only when both the middle tier 
and the auth tier are on the same machine.

> with problems like Site A was not Available at the time that site B
> disabled an account.  Better yet, do centralized auth.  This is the
> Internet.  Or are you saying that site B is the centralized auth source.

The one application I was asked this for was like this: an B2B web 
application that could either be installed in an intranet or on the web. That 
would be multi customer, that means it could be configured to serve different 
companies. Each company had his users, at various levels (admins, operators 
etc). Admins for example could personalize stuff and add users to their 
company's group. Then the application would contact a centralized site that 
provided some business information on firms and products, on a pay basis. 
Each company that uses this app would have the possibility to download and 
keep in the db for his slice of application, on a pay basis, some precious 
list of products/producers/contacts tailored to their needs, from the mother 
site (Site B). So single users were registered locally, but belonged to a 
determinate client company, which in all had some access to the centralized 
DB of precious contacts, and the amount of data downloaded would be accounted 
and payed for by volume by the client company in all, not by the single user. 
With this info, the application provided a mean to open multiple online 
negotiations on  preventives with the furnishing firms/contacts, and keep 
track of each negotiation for historic analysis. The whole business was that 
Site B, the mother site, would help fashion firms enter in contact with 
selected producers by building a virtual marketplace for them, and by 
selingg them the contacts and this service itself.

BTW, this went into nowhere for some other reason, but when I did the 
analysis I thought to adapt phplib + XMLRPC for it and made, I think, a good 
design, that unfortunately was never payed to me ;-(

Gian