Re: AuthCookie questions
Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
RE: AuthCookie questions
Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. 1. Foreign server, foreign.foo.com, presents a form to a user requesting userid/password. Foreign server accepts credentials and creates simple session cookie whose domain is foo.com containing a string of unencrypted key/value pairs. 2. User comes to my local server, local.foo.com, and sends along his cookie for domain foo.com. I need to parse out one of the key/value pairs and populate an environment variable (aside from REMOTE_USER) with the pair's data. If the user comes without the cookie or without appropriate data in the cookie, I need to redirect him to foreign. I am also asked to not create any other cookies. All the data I need is in the one cookie that comes from foreign. So, my needs boil down to: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group -Original Message- From: Michael Schout [mailto:mschout;gkg.net] Sent: Tuesday, October 22, 2002 2:00 PM To: Christian Gilmore Cc: Modperl Mailing List (E-mail) Subject: Re: AuthCookie questions Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: AuthCookie questions
Christian Gilmore wrote: Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. [...] On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. It sounds like you are already aware that it lacks security. The important thing to remember about cookies is that unless you use some kind of cryptographic signature to verify them you have absolutely no idea if the cookie came from your site or not. People can very easilly put whatever they want in a cookie to send to your site usingone of the thousands of HTTP testing programs and libraries, and if you use that cookie as a key to a data structure they may be able to gain access to other people's data. Even if you use a crypto signature they can still sniff someone else's legit cookie off the wire, but at least you can prevent them from tampering with the contents of the cookie. Never trust the client. - Perrin
Re: AuthCookie questions
Christian Gilmore wrote: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. Sounds to me like you really dont need AuthCookie at all. You could just as easily do all of this by writing a PerlAccessHandler that does the above things. I'll second Perrin's comments. You definately have security problems with this. The only way to do this securely is to cryptograpically sign the cookie and to encrypt the data on the wire using SSL. Mike
Re: AuthCookie questions
check here http://modperl.home.att.net Peter - Original Message - From: Christian Gilmore [EMAIL PROTECTED] To: 'Michael Schout' [EMAIL PROTECTED] Cc: 'Modperl Mailing List (E-mail)' [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 12:13 PM Subject: RE: AuthCookie questions Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. 1. Foreign server, foreign.foo.com, presents a form to a user requesting userid/password. Foreign server accepts credentials and creates simple session cookie whose domain is foo.com containing a string of unencrypted key/value pairs. 2. User comes to my local server, local.foo.com, and sends along his cookie for domain foo.com. I need to parse out one of the key/value pairs and populate an environment variable (aside from REMOTE_USER) with the pair's data. If the user comes without the cookie or without appropriate data in the cookie, I need to redirect him to foreign. I am also asked to not create any other cookies. All the data I need is in the one cookie that comes from foreign. So, my needs boil down to: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group -Original Message- From: Michael Schout [mailto:mschout;gkg.net] Sent: Tuesday, October 22, 2002 2:00 PM To: Christian Gilmore Cc: Modperl Mailing List (E-mail) Subject: Re: AuthCookie questions Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: AuthCookie help
Jian Zhen wrote: Hi all, I have been scratching my head for a day now trying to figure out how to make AuthCookie work. I note that you have PerlSetVar WhatEverSecure 1 in your config. If that is the case, make sure you are accessing the from using HTTPS, not HTTP. This has been a common cause of this behaviour. With WhatEverSecure 1, the cookie will only be returned to the server on an SSL connection, but not a plain HTTP connection. I probably should document this better in the POD docs... Mike
Re: AuthCookie help
Mike, Thx for your response. I am actually accessing it through https and still have the same problem. I tried putting things in either .htaccess or httpd.conf, but that doesn't seem to help either. Any other idea what might be wrong here? thx again for ur help // Jian Michael Schout ([EMAIL PROTECTED]) [020515 09:11]: Jian Zhen wrote: Hi all, I have been scratching my head for a day now trying to figure out how to make AuthCookie work. I note that you have PerlSetVar WhatEverSecure 1 in your config. If that is the case, make sure you are accessing the from using HTTPS, not HTTP. This has been a common cause of this behaviour. With WhatEverSecure 1, the cookie will only be returned to the server on an SSL connection, but not a plain HTTP connection. I probably should document this better in the POD docs... Mike
Re: AuthCookie login ?
On Fri, 5 Apr 2002, Geoffrey Young wrote: Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful Yes, do it in authen_cred() after you have checked the credentials, but before returning the username. authen_cred() is only called when you submit the login form. Regards, Michael Schout (AuthCookie maintainer).
Re: AuthCookie login ?
Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful attempt). you have control here to execute code only when a valid user is found, since it's up to you to determine if the user is valid. authen_ses_key() then checks whether the cookie itself (containing the session key) is valid. at least this is how I remember it working - it's been a while since I've worked with AuthCookie. --Geoff
Re: AuthCookie access denied messages
David Young wrote on Mon, Aug 20 2001 (12:36:19 -0400): Before I tackle this myself, has anyone added functionality to AuthCookie so that it will report *why* a user is being asked to login? Currently, if a perldoc Apache::AuthCookie /AuthCookieReason cu, -- Toni Andjelkovic [EMAIL PROTECTED]
Re: AuthCookie access denied messages
you can set these in yourself by overwriting
the AuthCookie Response method
you should catch these in your
own subs and send back messages
for instance
in my Auth.pm authen_ses_key sub
[ snip ]
In addition to that, what I found confusing was actually getting authen_ses_key to be
called in the first place, after a failed login attempt.
The stock authen_cred returns data that will be loaded into a cookie only if
authentication is successful. To get authen_ses_key to be called after an
unsuccessful attempt, your authen_cred needs to do this:
if ( check_creds() ) {
# make a ticket, start a session, etc
return $valid_ticket_data;
}
else {
return oops; # make sure we never accept this as a valid cookie!
}
Now authen_ses_key gets called and AuthCookie will set AuthCookieReason to bad_cookie
if you return undef. Also, you now have a chance to set other environment variables.
...Steve
--
Steve van der Burg
Information Services
London Health Sciences Centre
(519) 685-8300 ext 35559
[EMAIL PROTECTED]
Re: AuthCookie access denied messages
David Young wrote:
Before I tackle this myself, has anyone added functionality to AuthCookie so
that it will report *why* a user is being asked to login? Currently, if a
user enters in a wrong username or password, they just get redirected back
to the login form with no explanation.
Thanks,
--David
you can set these in yourself by overwriting
the AuthCookie Response method
you should catch these in your
own subs and send back messages
for instance
in my Auth.pm authen_ses_key sub
if ($checks ne 1 ||$id eq '') {
$r-subprocess_env('AuthCookieReason2', 'does not check or you have
no id');
return '';
}
else {
return $creds[0];
}
then in login.cgi
my $error=$r-prev-subprocess_env('AuthCookieReason2')
|| $r-prev-subprocess_env('AuthCookieReason');
i then just put this erro in as a template param
which handles
my error or else give default 'no cookie one'
hope that helps
also you might wanna try setting
PerlSetVar AuthCookieDebug 3
for longer messages in logs till you get then hang of it
Re: AuthCookie access denied messages
Hi there, On Mon, 20 Aug 2001, David Young wrote: Before I tackle this myself, has anyone added functionality to AuthCookie so that it will report *why* a user is being asked to login? Currently, if a user enters in a wrong username or password, they just get redirected back to the login form with no explanation. It's generally considered a security hole to report things like invalid user id to a user who fails to get a login, because when he finally gets invalid password he knows he's got a valid user id... 73, Ged.
Re: AuthCookie access denied messages
Agreed, however I'd like to at least say The username and/or password you entered was not recognized. From: Ged Haywood [EMAIL PROTECTED] Date: Tue, 21 Aug 2001 00:36:33 +0100 (BST) To: David Young [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: AuthCookie access denied messages It's generally considered a security hole to report things like invalid user id to a user who fails to get a login, because when he finally gets invalid password he knows he's got a valid user id... 73, Ged.
Re: AuthCookie question
Chad Phillips [EMAIL PROTECTED] said something to this effect on 07/06/2001: Hi, I have set up Authcookie. I modified the sample scripts for my sight. Everything works except when the wrong password is entered. When an invalid user/password is entered, instead of re-displaying the login page, I get a 302 Found error to url http://myhost/LOGIN Any ideas on what I may have wrong? I didn't see any ErrorDocument settings; try setting it: ErrorDocument 401 http://myhost/LOGIN Of course, this will be for the whole virtual server, but whenever someone doesn't authenticate correctly, they'll be redirected to the login page. (darren) PS The sig is randomly generated, and not aimed at you... -- The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer.
Re: AuthCookie expansion
RB == Rich Buckley [EMAIL PROTECTED] writes: RB credentials have been verified. What I would like to do is redirect RB to a home page looked up from the database. The database lookup is RB trivial but where and how is the best place to do the redirection RB within the AuthCookie framework ? Make the destination of the login page be your redirect script, which then does the lookup based on the login ID and redirects the user. Either that or use a rewrite rule with the rewrite engine based on user ID and some map that converts user IDs to pages. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: AuthCookie
Kiran Kumar wrote: Hi, I have Installed AuthCookie Module but it does not work on netscape (4.7) but works on IE . In netscape after I logout and later i req Hello all, uest a protected page i still get the page ,Can anyone help me on this . netscape could cache the requested page page look the cookie send ( set warn when accepting cookie ) on unlog Thanks in advance Kiran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Don't be irreplaceable, if you can't be replaced, you can't be promoted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AuthCookie
Check your apache logs.. I don't think your server is actually sending the protected page, Netscape is showing you a cached version. I think this is a bug in Netscape 4.7 (for linux anyway), because that happens to me occasionally even with "Cache-Control: no-cache" and no "Expires:" header. If you click reload, it will actually hit the server and show you your login script page again. ditto that Netscape 4.7 for windoze also has this "feature". Basically the cache settings in the preferences settings are bogus. If you unload netscape completely and re-load it (windoze) it will really do what you ask, but not on a user site by site basis as you browse. -- does the same thing for cookies, java downloads, page downloads, etc -- does NOT check with the server when the preference settings would indicat that it should. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AuthCookie
Check your apache logs.. I don't think your server is actually sending the protected page, Netscape is showing you a cached version. I think this is a bug in Netscape 4.7 (for linux anyway), because that happens to me occasionally even with "Cache-Control: no-cache" and no "Expires:" header. If you click reload, it will actually hit the server and show you your login script page again. HTH, -Adi Kiran Kumar wrote: Hi, I have Installed AuthCookie Module but it does not work on netscape (4.7) but works on IE . In netscape after I logout and later i request a protected page i still get the page ,Can anyone help me on this . Thanks in advance Kiran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AuthCookie solution
-Original Message- From: Michael [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 15, 2000 10:20 PM To: [EMAIL PROTECTED] Subject: Re: AuthCookie solution a little off the subject, but close. it the pointer for login is a complete URL ie http://foo.com/login.pl then the $r-prev-args; seem to get lost. There is real application for this sort of thing and I would like to figure out how to make it work. Any ideas why it does not? $r-prev() only knows about the previous internal redirect. $r-header_out(Location = 'http://foo.com/login.pl'); results in a full redirect (ie a new request) as an aside, I've found it safer to when using $r-prev to code like my $query = $r-prev ? $r-prev-args : $r-args; because $r-prev is undefined on $r-is_initial_req() which leads to runtime errors (beware of my $x if 0 coding, too :) depends on your situation, though - YMMV... --Geoff Michael [EMAIL PROTECTED]
Re: AuthCookie solution
At 04:19 PM 11/15/00 -0500, Charles Day wrote:
# We added the line below to AuthCookie.pm
$r-header_out("Location" = $args{'destination'}.$args{'args'});
Why pass a new argument? Can't you just add the query string onto the
destination field in your login.pl script?
Something like the untested:
my $uri = $r-prev-uri;
my $query = $r-prev-args;
$uri = "$uri?$query" if $query;
print qq[INPUT TYPE=hidden NAME=destination VALUE="$uri"];
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: AuthCookie solution
At 04:19 PM 11/15/00 -0500, Charles Day wrote:
# We added the line below to AuthCookie.pm
$r-header_out("Location" = $args{'destination'}.$args{'args'});
Why pass a new argument? Can't you just add the query string onto
the destination field in your login.pl script?
Something like the untested:
my $uri = $r-prev-uri;
my $query = $r-prev-args;
$uri = "$uri?$query" if $query;
a little off the subject, but close.
it the pointer for login is a complete URL ie http://foo.com/login.pl
then the $r-prev-args; seem to get lost. There is real application
for this sort of thing and I would like to figure out how to make it
work. Any ideas why it does not?
Michael
[EMAIL PROTECTED]
Re: AuthCookie
At 03:30 PM 11/03/00 -0500, Charles Day wrote:
The follow also holds true:
http://www.mydomain.com/index.cgi?a=blablablab=blablabla
gets redirected to:
http://www.mydomain.com/index.cgi
If I remember, that's just due to the example in the AuthCookie POD that uses
$r-prev-uri to set the destination parameter in the Login script. uri()
doesn't include the query string, IIRC.
I've replaced the following line in AuthCookie.pm
$r-header_out("Location" = "$args{'destination'}");
with:
$r-header_out("Location" = "$ENV{HTTP_REFERER}");
I wouldn't do that as it's client dependent (and in quotes ;).
And we don't loose the data. Is there a better mod_perlish way to do this
and are there buffer overflow risks involved?
Use a mod_perl handler or Apache::Registry script for the login script, and
include $r-prev-args. There's probably better ways to get the full URL,
but I just put uri() and args() together.
I suppose if your login.pl script could just place the current fields
passed in on the POST to the destination parameter passed to AuthCookie.
Then your script would get the parameters, they would just be a GET instead
of a POST. Can be kind of ugly.
Bill Moseley
mailto:[EMAIL PROTECTED]
