[SSSD] design discussion: Authenticate against cache in SSSD

Sumit Bose sbose at redhat.com
Wed Apr 22 09:09:33 UTC 2015


On Tue, Apr 21, 2015 at 03:39:11PM +0200, Pavel Reichl wrote:
> Hello,
> 
> I have prepared wiki page with proposal how to implement the feature from the subject.
> 
> https://fedorahosted.org/sssd/wiki/DesignDocs/CachedAuthentication
> 
> For your convenience I paste the content here.

Hi Pavel,

thank you for taking care of this, please find comments in-line.

bye,
Sumit

> 
> Thanks!
> 
>  = Authenticate against cache in SSSD =
> 
> Related ticket(s):
>  * https://fedorahosted.org/sssd/ticket/1807
> 
> === Problem statement ===
> SSSD should allow cache authentication instead of authenticating directly against network server every time. Authenticating against the network many times can cause excessive application latency.
> 
> === Use cases ===
> In environments with tens of thousands of users log in process may become inappropriately long, when servers are running under high workload (e.g. during classes, when may users log in simultaneously).
> 
> === Overview of the solution ===
> Add new domain option `cached_authentication_timeout` describing how long can be cached credentials used for cached authentication before on-line authentication must be performed. Update PAM responder functionality for forwarding requests to domains by checking if request can be served from cache and if so execute same code branch as for off-line authentication instead of contacting the domain.
> 
> === Implementation details ===
> 
> * extend ''struct pam_auth_req''
>  * add new field `use_cached_auth` (default value is false)
> * extend ''pam_dom_forwarder()''
>  * obtain value of domain option `cached_authentication_timeout`

I think you can add a new element to pam_ctx for this like we currently
do this e.g. with id_timeout.

Please check if cached_authentication_timeout is not larger than
offline_credentials_expiration (given in days) and use the smaller of
the two.

>  * do not forward request to domain if
>   * domain uses cached credentials and
>   * `cached_authentication_timeout` is greater than 0 and
>   * last online log in of user who is being authenticated is not stale (< ''now()'' - `cached_authentication_timeout`) and
>   * PAM request can be handled from cache (PAM command is SSS_PAM_AUTHENTICATE or SSS_PAM_ACCT_MGMT)

I think for SSS_PAM_ACCT_MGMT you have to forward the request to the
backends because otherwise you skip access control completely. Even if
offline the access control validation is done in the backends and we do
not save a result to the cache mainly because there might no be a single
result. E.g. access control might depend on the service and just knowing
that access was granted for service A does not help to determine if
access for service B should be granted as well. Nevertheless the backend
might have added sufficient information to the cache to do the
evaluation for service B even if offline.

To speed up access control as well we could add a flag like
'may_use_cached_data' in the request to the backend which tells the
backend the cached data can be used for the evaluation. But I think this
would be a different RFE. The one at hand should only handle
SSS_PAM_AUTHENTICATE.


>    * then set `use_cached_auth` to true
>    * call ''pam_reply()''
> * extend ''pam_reply()''
>  * extend condition for entering into block processing case when pam_status is PAM_AUTHINFO_UNAVAIL even for `use_cached_auth` being true
>  * while in this block and if PAM command is SSS_PAM_AUTHENTICATE then set `use_cached_auth` to false to avoid cyclic recursion call of ''pam_reply()'' which is subsequently called from ''pam_handle_cached_login()''.
> * introduce function ''sysdb_get_user_lastlogin()''
>  * returning time of last online performed log in for given user

but only if pam_verbosity is high enough

> 
> === Configuration changes ===
> A new domain option `cached_authentication_timeout` will be added. The value of this option is time period for which cached authentication can be used. After this period is exceeded on-line authentication must be performed. The default value would be 0, which implies that this feature is by default disabled.
> 
> === How To Test ===
> 1. set `cached_authentication_timeout` in sssd.conf to some non-null value (e.g. 120)
> 1. erase SSSD caches and restart SSSD
> 1. log in as user from domain which stores credentials and then log out and log in again. The second log in should use cached credentials. Output should by similar to this, especially note the line starting with: '''Authenticated with cached credentials'''
> {{{
> devel at dev $ su john
> Password:
> john at dev $ exit
> devel at dev $ su john
> Password:
> Authenticated with cached credentials, your cached password will expire at: Wed 22 Apr 2015 08:47:29 AM EDT.

as mentioned above I think this message should not be send by default
because it might irritate the user.

> john at dev $
> }}}
> 1. for the `cached_authentication_timeout` seconds since the 1st log in all subsequent log in attempts (for the same user) should be served from cache and domain should not be contacted, this can be verified by changing password at server.
> 1. after passing more than `cached_authentication_timeout` seconds since the 1st log in an on-line log in should be performed and new password must be used.

I wonder what should happen after a local password change. We save the
hash of the new password to the cache but I think we do not change the
last online auth time here. Shall we do cached authentication with the
new password immediately here or shall we go to the backend at least
once to make sure the backend knows about the new password. I think I
would prefer the latter.

Please add test with wrong password as well to check if
offline_failed_login_attempts and offline_failed_login_delay are
respected here as well (I have not doubt about this because the same
code patch will be used but better be on the save side and be able to
detect regression early).

As an alternative we might want to send the request to the backend if
cached authentication fails. This would cover the case where the user
changed the password on the server and tries to login in to a system
where the cached_authentication_timeout is not expired yet with the new
password. 

> 
> === Authors ===
> * Pavel Reichl <preichl at redhat.com>
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list