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[1]. 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. Michael [1] http://www.ja-sig.org/products/cas/index.html > > We are using Apache 2 and PHP. > > Steve > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
