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 <[email protected]> wrote: > On 03 Dec 2013, at 5:29 PM, Thomas Eckert <[email protected]> > 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 > -- > >
