torriem at chem.byu.edu
Sat Jun 17 17:22:52 MDT 2006
On Sat, 2006-06-17 at 17:15 -0600, Stephen Smith wrote:
> I need to do the following:
> A browser contacts server A to get a logon screen. On submit, the
> username and password need to be sent to Server B that will validate the
> username/password, then send authorization back to a page on server A
> that will redirect the browser based on the type of authorization returned.
> The problem, we would like to pass the username/password to computer B
> as opaque data (not as arguments to the url. Additionally, we would
> like to pass the authorization back to server A as opaque data. The
> servers are no co-located.
> Is this possible?
Is is possible. But it will require some cooperation and communication
between the two servers. An example of such a system is CAS. We
actually use CAS itself to do centralized authentication for all of our
web apps, which live on different servers. We really like it. However
the CAS server is written in Java. The principles of this type of
authentication could be done in any language (in fact a C++ CGI version
of the CAS server has been implemented by someone).
The best (not the easiest) and securest way to accomplish this is to
adopt the kerberos trusted-third part model. If your client can
authenticate against the trusted entity (CAS in my case), then it
receives a special cryptographic cookie that entitles it to services on
a variety of servers that participate in the CAS system. Each service
checks the service-granting cookie with the central server, which then
grants the client a service-granting cookie with the service recognizes.
After that the sessions are created and the service trusts you because
the third party (which it trusts) verified you. It sounds really
complex (because it kind of is), but works very well. Even crossing
domain name boundaries is possible (proxy tickets).
Another solution I can think of is to have server A set a cookie (some
crypto hash) that will eventually be sent to server B by the client's
browser. After setting the cookie, Server A will have to contact Server
B via a web services system and exchange some kind of info so that
Server B can verify the hash.
> We are using Apache 2 and PHP.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG