lwp and IFRAME

novitiate has asked for the wisdom of the Perl Monks concerning the following question:

Looking for a way to portalize a couple of apps that run on disparate web servers. I have the apps running in IFRAMEs right now, but I want to create a single login scenario (they are all protected with Basic over SSL), so that as a user's apps come up, there is no need for the login from the respective IFRAMEs to appear (some run up to five apps). Is there anyway to use LWP (or some other methods) to do the authentications with the IFRAME apps on behalf of the user ?

DIAGRAM:

                          |IFRAME 0|
                           /
                    basic+ssl($user,$pw0) 
                         /
                        /
$user---login-->|PORTAL|======Basic+SSL($user,$pw1)===|IFRAME1|

Edit by tye

Comment on lwp and IFRAME

Replies are listed 'Best First'.
Re: lwp and IFRAME by traveler (Parson) on May 17, 2001 at 01:19 UTC
I have seen something I think is very close to what you want. The user logs in to HostA (W2k). HostA does authentication over SSL. HostA sends a domain cookie (.mydomain.com) to the user containing a long unique string (many characters). If the user connects to HostB (linux) the browser sends the cookie to HostB which in turn sends the cookie value back to HostA (via LWP) for validation. HostA returns a short http message to HostB with an indication that the auth succeeded (or not). You'll of course need to protect the directories you want protected (e.g. with .htaccess under Apache). You may want to make the cookie values "one-time" or associate other info with their use depending on what you are trying to do. --traveler	[reply]
Re: Re: lwp and IFRAME by novitiate (Scribe) on May 17, 2001 at 19:56 UTC
I was remiss in leaving out some details: 1.) The apps in the IFRAMEs don't belong to me and I have no influence on the design of those servers. 2.) The login at HostA is arbitrary and slightly irrelevant; It's kind of like, I have subscriptions to four commercial sites that use Basic/SSL validation and I want to condense the logins into a single one of my choosing. I hope that explains it a little better. humbly, novitiate	[reply]
Re: Re: Re: lwp and IFRAME by traveler (Parson) on May 17, 2001 at 23:13 UTC
Ahhh, then on portal you'll have to save the login info somewhere and supply it to the other hosts. I think the key that you need to know is how to use basic auth. Does something like this not work for you? `my $req = new HTTP::Request('GET', $url_1); $uid = 'user1'; $pass = 'pass1'; $req->authorization_basic($uid, $pass);` [download] --traveler	[reply] [d/l]
Re: lwp and IFRAME by sutch (Curate) on May 17, 2001 at 19:41 UTC
If all of the applications run on different servers, you will need at least one trusted server to maintain users' passwords for all applications (unless you can guarantee that each user uses the same username/password pair for each application). In your case, it would make sense to have the portal be the server to maintain all of the passwords. This will allow the portal to accept user logins while requesting application content with each user's login information. A major problem with this method is that you will need to ensure that the portal (or login server) is kept informed of all user changes (new users, removed users, updated passwords) for each application. If you have control of the applications and can modify their source code, you could move all of the authentication to a separate server. This would allow users to maintain one username/password pair for all applications, and would allow the portal to request information from applications while supplying each user's authentication information retrieved from some authentication server. My organization is in the process of moving authentication to a separate server to allow for a portal as described by novitiate, and it seems to work well--for both end users and developers. But setting up the infrastructure is taking quite a bit of effort. I would be interested in hearing about how others have tackled this problem.	[reply]


Perl-Sensitive Sunglasses
	PerlMonks