I will assume a forms based login and cookie managed sessions but it is not limited to this setup.
A user connects, is queried for authentication, submits credentials and is subsequently allowed access. The session is established via a cookie. If the user credentials were accepted by a custom provider, this custom provider does not know whether the client sent the session cookie or whether the user just filled in the authentication form but this might be of relevance to how the custom provider has to react. Suppose, due to internal logic (see below for an example) the custom provider needs to confirm the user credentials by having the user log in again. Obviously, this should not happen if the user just filled in and submitted the form but it should happen if the user's client sent the authentication details via the session cookie. To decide correctly the custom provider needs to be able to discern between the credential sources. In my case the custom provider has to maintain a module local session cache, where each user is mapped to a cache entry in order to prevent unnecessary calls to the underlying authentication daemon. Calls to the daemon are costly compared to accessing the module local session cache. Entries in the session cache can become invalid in between user requests, e.g. by a time out. When such a session cache entry is accessed (due to a request by the corresponding user) the time out is realized by the custom provider and the session entry is invalidated. Now the custom provider needs to decide whether to use the existing user credentials which were handed down into the provider by apache or whether to force the user to confirm the credentials by returning DECLINED - which causes the form to be displayed again. 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). On Tue, Dec 3, 2013 at 1:15 PM, Graham Leggett <[email protected]> wrote: > On 03 Dec 2013, at 1:27 PM, Thomas Eckert <[email protected]> > wrote: > > > I have been having problems with mod_auth_form on returning DENIED from > my custom auth provider. This provider has it's own module-local session > cache, where stuff like accessible paths, credentials and the like are > stored to avoid having to query an external (and expensive) authentication > daemon. Once such a session is accessed by the user browsing (e.g. with the > corresponding session cookie) I might need to invalidate the session (e.g. > time out). After failing the appropriate checks I would "return DENIED" but > this had an unpleasant drawback: If a user accessed the session by sending > the filled-in form (e.g. on a new device with no cookie) the code would > still return DENIED if the session was invalid for whatever reason. This > resulted in the user being shown the form again, even though the user just > filled in the form correctly. > > I'm not fully understanding the flow you're describing. Are you sure > you're not accidentally password protecting / session protecting the login > form? > > The login form needs to be accessible without any restrictions on > authn/authz or session, otherwise httpd will deny access to the form too. > > Can you clarify the flow of requests during login that you are expecting? > > Regards, > Graham > -- > >
