httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Eckert <thomas.r.w.eck...@gmail.com>
Subject Re: make mod_auth_form tell you where the credentials came from
Date Tue, 03 Dec 2013 17:04:11 GMT
There are two type of sessions:
  * sessions by mod_session which are used to maintain a mapping between
user requests and "apache's session"
  * sessions in my custom provider, which are used to prevent accessing the
underlying auth daemon if not necessary

The custom provider itself is fairly simple, as it just registers in the
AUTHN_PROVIDER_GROUP with a simple check_password(r, user, pass) function.
The module's configuration (server config) contains a hash which I referred
to as the "module's local session cache". This module local session cache
is not visible to anything else then the custom provider module and there
is no interaction between that hash and any other part of apache - aside
from mutex locks/unlocks around it for accessing the module internal
session cache securely (worker mpm).

mod_auth_socache is not used.

> The end user has never logged in, so they get a form, they enter
credentials, they are logged in. Time passes, a session of some kind
expires (a session provided by mod_session,
> or an internal unrelated session?), and the user… has to log in again?

Basically, yes.

 1 user tries to browse protected resource
 2 user is redirected to form
 3 user fills in and submits form
 4 custom auth provider receives the user credentials
 5 custom auth provider sets up internal session
 6 custom auth provider returns OK
 7 mod_session/mod_session_cookie set up their session and cookie (a part
of this probably happens before step 4 already but that doesn't matter)
 8 user is directed to whatever was given by AuthFormLoginsuccessLocation
 9 time passes and custom provider internal session expires
10 user tries to browse protected resource, user's client submitting the
cookie
11 based on the session cookie the user name/pass is extracted
12 custom auth provider receives the user credentials
13 custom auth provider looks up it's own session in it's module internal
session cache
14 custom auth provider realizes the provider internal session expired
15 custom auth provider returns DECLINED to force the user to log in again
16 continue at step 2

Now suppose the following
<http://httpd.apache.org/docs/current/mod/mod_auth_form.html#authformloginsuccesslocation>

21 user tries to browse protected resource
22 user is redirected to form
23 user fills in and submits form
24 custom auth provider receives the user credentials
25 custom auth provider sets up internal session
26 custom auth provider returns OK
27 mod_session/mod_session_cookie set up their session and cookie
28 user is directed to whatever was given by AuthFormLoginsuccessLocation
29 time passes and custom provider internal session expires
30 user tries to browse protected resource BUT user's client DOES NOT
submit the cookie (browser private mode, different browser, completely
different device, etc.)
31 user is redirected to form
32 user fills in and submits form
32 custom auth provider receives the user credentials
33 custom auth provider looks up it's own session in it's module internal
session cache
34 custom auth provider realizes the provider internal session expired

After step 34, the custom provider should *not* return DECLINED because it
would have the user be presented with the login form even though the user
just submitted the correclty filled-in form. Instead, the custom provider
should go on using the credentials it was given.

In the custom provider, is there a way to know about the difference with
currently existing means ?



On Tue, Dec 3, 2013 at 4:45 PM, Graham Leggett <minfrin@sharp.fm> wrote:

> On 03 Dec 2013, at 5:29 PM, Thomas Eckert <thomas.r.w.eckert@gmail.com>
> wrote:
>
> > This whole process is important for supporting two factor authentication
> - in my example with OTP - but I doubt this is the only use case. In
> general it's a good idea to let the auth providers know where the user
> credentials came from (eg. headers vs. body).
>
> I see a possible technical solution to something, but I don't yet
> understand the problem that technical solution is trying to solve.
>
> The end user has never logged in, so they get a form, they enter
> credentials, they are logged in. Time passes, a session of some kind
> expires (a session provided by mod_session, or an internal unrelated
> session?), and the user… has to log in again?
>
> I get the sense you're fighting against httpd's AAA modules instead of
> using them. Are you using mod_auth_socache to cache the credentials or
> something else? Are you using mod_session to implement your session or
> something else?
>
> Regards,
> Graham
> --
>
>

Mime
View raw message