how to pass authorization to another application

[taylor.ettema]

I wish to create an application that will be spawned within a host web
application after the container app has authorized a user. These two
apps are seperately developed/maintained, and can only share
information via the normal methods (post/get, cookies, etc...). What
is the best and most secure way to pass authorization to the spawned
application?

[Carl Vondrick]

ta***********@gmail.com wrote:

I wish to create an application that will be spawned within a host web
application after the container app has authorized a user. These two
apps are seperately developed/maintained, and can only share
information via the normal methods (post/get, cookies, etc...). What
is the best and most secure way to pass authorization to the spawned
application?

So you basically have two applications/websites and you want to
authenticate a login?

If they are hosted on the same server, simply connect to the same database.

If not, have a validater on the authentication app. This receives the
username and and password, then returns either if it's valid or not.
Note that the validater would never give out hashes or usernames -- it
just tells you if something is correct.

Carl

[Taylor]

They are not on the same server. There is no shared internal method of
communicating, so they can only interact via get/post, and cookies.
The host application will authenticate the user, and then it needs to
pass the username and something that proves they've been authenticated
by the host app to my sub-app.

[Jerry Stuckle]

Taylor wrote:

They are not on the same server. There is no shared internal method of
communicating, so they can only interact via get/post, and cookies.
The host application will authenticate the user, and then it needs to
pass the username and something that proves they've been authenticated
by the host app to my sub-app.

You have a problem then. Web server authentication (i.e. through
..htaccess, etc.) is on a per-site basis. Your browser will not send
authentication information from one server to another.

Cookies are the same way - the browser will not under normal conditions
pass a cookie meant for one host on to another. Either one would be a
severe security hole.

However, if the second server is a subdomain, you can use the domain
parameter of setcookie() to specify the cookie will be available to all
subdomains. See the PHP doc for setcookie() for more information.

However - warning. You should NOT rely on cookies for authentication.
It's too easy for someone to edit the cookie (since it is sent to their
machine) and authorize themselves - bypassing all of your security.

Perhaps another way (although I haven't tried) is to create a proxy on
the first server and have it authenticate then pass on the request to
the second one. The second server could then be set to completely block
requests coming from other than the first server.

Not easy, but more secure.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Colin McKinnon]

Taylor wrote:

They are not on the same server. There is no shared internal method of
communicating, so they can only interact via get/post, and cookies.
The host application will authenticate the user, and then it needs to
pass the username and something that proves they've been authenticated
by the host app to my sub-app.

The best solution depends on how the user moves from site to the other,
whether HTTPS is involved and whether they have same FQDN. But lets take
the simplest case - where there is none of that:

on server A:

function getToken($username, $encryption_key)
{
$token=base64_encode(encrypt($username . "|" . time()));
return($token);
}

and add the token into the URL you are linking with or as a hidden field in
any forms being submitted to the other server. The at the other end:

function check_auth($token, $encryption_key)
{
$token=base64_decode($token);
$token=decrypt($token);
list($username, $timestamp)=explode('|',$token);
if (abs(time()-$timestamp)>60) { // more than 60 seconds apart
return(false);
} else {
return($username);
}
}

Obviously this is not going to prevent replay attacks - really you should be
using a challenge based mechanism.

The most efficient solution is to push the encryption and validation down to
the transport layer using a VPN though.

C.

[Taylor]

Hmmm, I think we're all on different pages, but I think Colin came
closest to what I'm getting at. I think I found a solution:

This sub-site (like I've said, it can share no special links with the
other site like VPN, database, common server, etc...) is designed to be
invoked from many different "host" sites, as a sort of "service" built
into other website. The sub-site is hosted on an entirely different
platform, and must be invoked by get/post, unless there is some other
clever idea.

My solution is to have a secret key for each "host" site that uses my
sub-site service. When the host site authenticates a user, the host
site invokes the sub-site with a query string of an md5 hash of the
concatenation of the secret key and the user's username, along with an
unencrypted version of the username (so I know who's authenticated).
The sub site then checks to make sure the md5 hash matches what is
expected.

What do you think?

Colin McKinnon wrote:

Taylor wrote:

They are not on the same server. There is no shared internal method of
communicating, so they can only interact via get/post, and cookies.
The host application will authenticate the user, and then it needs to
pass the username and something that proves they've been authenticated
by the host app to my sub-app.

The best solution depends on how the user moves from site to the other,
whether HTTPS is involved and whether they have same FQDN. But lets take
the simplest case - where there is none of that:

on server A:

function getToken($username, $encryption_key)
{
$token=base64_encode(encrypt($username . "|" . time()));
return($token);
}

and add the token into the URL you are linking with or as a hidden field in
any forms being submitted to the other server. The at the other end:

function check_auth($token, $encryption_key)
{
$token=base64_decode($token);
$token=decrypt($token);
list($username, $timestamp)=explode('|',$token);
if (abs(time()-$timestamp)>60) { // more than 60 seconds apart
return(false);
} else {
return($username);
}
}

Obviously this is not going to prevent replay attacks - really you should be
using a challenge based mechanism.

The most efficient solution is to push the encryption and validation down to
the transport layer using a VPN though.

C.

[Robin]

Taylor wrote:

Hmmm, I think we're all on different pages, but I think Colin came
closest to what I'm getting at. I think I found a solution:

This sub-site (like I've said, it can share no special links with the
other site like VPN, database, common server, etc...) is designed to be
invoked from many different "host" sites, as a sort of "service" built
into other website. The sub-site is hosted on an entirely different
platform, and must be invoked by get/post, unless there is some other
clever idea.

My solution is to have a secret key for each "host" site that uses my
sub-site service. When the host site authenticates a user, the host
site invokes the sub-site with a query string of an md5 hash of the
concatenation of the secret key and the user's username, along with an
unencrypted version of the username (so I know who's authenticated).
The sub site then checks to make sure the md5 hash matches what is
expected.

What do you think?

I've done something like this in the past with a similar solution.

Host:
Authenticates user (normal db way) then when user whats to go to
sub-site the link is via a submitted form with a hidden field containing:

urlencode(rc4($rc4key,randomjunk().'|CODE|'.random junk().'|'.$username.'|'.gmdate('U')))
Sub-site:
validate page (linked to from Host) can then:

list($junk1,$codeword,$junk2,$username,$time)=expl ode('|',rc4($rc4key,urldecode($_POST['data'])))

then check $codeword=='CODE' (checks right rc4key was used)
and check $time within 60 secs (prevents replay attacks after a minute)
where rc4() is a RC4 (de)encryption function (doh!),
$rc4key is a big shared key, and
randomjunk() produces a random length string of random characters
(excluding '|')
Someone with more cryptography knowledge can now say which is the most
secure solution (or point out some major flaw in our processes).

Robin