design discussion: Authenticate against cache in SSSD

[Pavel Reichl]

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.

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`
  * 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)
    * 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

=== 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@dev $ su john
Password:
john@dev $ exit
devel@dev $ su john
Password:
Authenticated with cached credentials, your cached password will expire at: Wed 22 Apr
2015 08:47:29 AM EDT.
john@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.

=== Authors ===
* Pavel Reichl <preichl(a)redhat.com&gt;

[Sumit Bose]

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@dev $ su john
>  Password:
>  john@dev $ exit
>  devel@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@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(a)redhat.com&gt;
>  
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

On Wed, Apr 22, 2015 at 11:09:33AM +0200, Sumit Bose wrote:
>  > * 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. 
The design page is not too specific about this detail, but I think Pavel
intended to have a per-domain option, which would then make sense to
include in a per-domain data structure, maybe even sss_domain_info.

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

[Sumit Bose]

On Wed, Apr 22, 2015 at 12:02:06PM +0200, Jakub Hrozek wrote:
>  On Wed, Apr 22, 2015 at 11:09:33AM +0200, Sumit Bose wrote:
>  > > * 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.
>  
>  The design page is not too specific about this detail, but I think Pavel
>  intended to have a per-domain option, which would then make sense to
>  include in a per-domain data structure, maybe even sss_domain_info. 
ah, I see, makes sense. Maybe a global/domain-specific option like we
have for other case as well might fit here as well. Please note that we
currently cannot set the per-sub-domain.

bye,
Sumit

>  
>  > 
>  > Please check if cached_authentication_timeout is not larger than
>  > offline_credentials_expiration (given in days) and use the smaller of
>  > the two.
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Pavel Reichl]

On 04/22/2015 11:09 AM, Sumit Bose wrote:
>  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 
Thank you very much for comments, I'll update the page, but please see 
the responses inline first.
> > 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. 
Yes, it will be better than parsing the value every
time from confdb, 
although as Jakub stated I intend to set this value per domain so 
sss_domain_info will be changed instead of pam_ctx.
>  Please check if cached_authentication_timeout is not larger than
>  offline_credentials_expiration (given in days) and use the smaller of
>  the two. 
Sure, I wanted just to document behavior but this is better.
> >   * 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. 
Understood, thanks for explaining.
>  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. 
OK, I'll file a ticket and we can defer it on Thursday. 
:-)
> >     * 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 
Sorry, I think I badly described this.
sysdb_get_user_lastlogin() would 
be used just to obtain value of last online login from sysdb while 
deciding in pam_dom_forwarder() whether authentication can be served 
from cache or BE must be contacted. No output to console should happen 
here.
> > === 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@dev $ su john
> > Password:
> > john@dev $ exit
> > devel@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. 
Yes, I will update design page that
pam_verbosity must be set to see 
this.  (I don't intend to add any console output)
> > john@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. 
I think we should definitely do online log in next time
user try to log 
in. Question is how?
1) I'm worried that if SYSDB_LAST_ONLINE_AUTH was set to 0 after local 
password change we would disable not even cached log in but even off 
line log in.
2) I could introduce SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN that 
would behave as SYSDB_LAST_ONLINE_AUTH but could be set to 0 as proposed 
in 1)
>  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). 
Sure.
>  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. 
Yes, I agree that we must do that.
1) We could  just set SYSDB_LAST_ONLINE_AUTH (or 
SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN) to 0 and require on line log 
in next time.
2) Try online log in immediately. I suppose this is preferred because it 
provides better user experience.
> > === Authors ===
> > * Pavel Reichl <preichl(a)redhat.com&gt;
> >
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

On Fri, 2015-04-24 at 11:16 +0200, Pavel Reichl wrote:
>  On 04/22/2015 11:09 AM, Sumit Bose wrote:
>  > 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
>  Thank you very much for comments, I'll update the page, but please see 
>  the responses inline first.
>  >
>  >> 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.
>  Yes, it will be better than parsing the value every time from confdb, 
>  although as Jakub stated I intend to set this value per domain so 
>  sss_domain_info will be changed instead of pam_ctx.
>  >
>  > Please check if cached_authentication_timeout is not larger than
>  > offline_credentials_expiration (given in days) and use the smaller of
>  > the two.
>  Sure, I wanted just to document behavior but this is better.
>  >
>  >>   * 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.
>  Understood, thanks for explaining.
>  >
>  > 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.
>  OK, I'll file a ticket and we can defer it on Thursday.  :-)
>  >
>  >
>  >>     * 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
>  Sorry, I think I badly described this. sysdb_get_user_lastlogin() would 
>  be used just to obtain value of last online login from sysdb while 
>  deciding in pam_dom_forwarder() whether authentication can be served 
>  from cache or BE must be contacted. No output to console should happen 
>  here.
>  >
>  >> === 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@dev $ su john
>  >> Password:
>  >> john@dev $ exit
>  >> devel@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.
>  Yes, I will update design page that pam_verbosity must be set to see 
>  this.  (I don't intend to add any console output)
>  >
>  >> john@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.
>  I think we should definitely do online log in next time user try to log 
>  in. Question is how?
>  1) I'm worried that if SYSDB_LAST_ONLINE_AUTH was set to 0 after local 
>  password change we would disable not even cached log in but even off 
>  line log in.
>  2) I could introduce SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN that 
>  would behave as SYSDB_LAST_ONLINE_AUTH but could be set to 0 as proposed 
>  in 1)
>  >
>  > 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).
>  Sure.
>  >
>  > 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.
>  Yes, I agree that we must do that.
>  1) We could  just set SYSDB_LAST_ONLINE_AUTH (or 
>  SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN) to 0 and require on line log 
>  in next time.
>  2) Try online log in immediately. I suppose this is preferred because it 
>  provides better user experience. 
+1 you should immediately try an online login if the password doesn't
match. It will allow a user to correctly login if the password was
indeed changed through another client. It will also make the server
failed auth counter go up if it was a password guessing attempt.
It will make password guessing attempts pay the full roundtrip to the
server, which helps deter local attacks even if we do not do any other
checks like we do for real offline auth.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Sumit Bose]

On Fri, Apr 24, 2015 at 11:16:05AM +0200, Pavel Reichl wrote:
>  On 04/22/2015 11:09 AM, Sumit Bose wrote:
>  >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
>  Thank you very much for comments, I'll update the page, but please see the
>  responses inline first.
>  >
>  >>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.
>  Yes, it will be better than parsing the value every time from confdb,
>  although as Jakub stated I intend to set this value per domain so
>  sss_domain_info will be changed instead of pam_ctx.
>  >
>  >Please check if cached_authentication_timeout is not larger than
>  >offline_credentials_expiration (given in days) and use the smaller of
>  >the two.
>  Sure, I wanted just to document behavior but this is better.
>  >
>  >>  * 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.
>  Understood, thanks for explaining.
>  >
>  >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.
>  OK, I'll file a ticket and we can defer it on Thursday.  :-)
>  >
>  >
>  >>    * 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
>  Sorry, I think I badly described this. sysdb_get_user_lastlogin() would be
>  used just to obtain value of last online login from sysdb while deciding in
>  pam_dom_forwarder() whether authentication can be served from cache or BE
>  must be contacted. No output to console should happen here.
>  >
>  >>=== 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@dev $ su john
>  >>Password:
>  >>john@dev $ exit
>  >>devel@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.
>  Yes, I will update design page that pam_verbosity must be set to see this.
>  (I don't intend to add any console output)
>  >
>  >>john@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.
>  I think we should definitely do online log in next time user try to log in.
>  Question is how?
>  1) I'm worried that if SYSDB_LAST_ONLINE_AUTH was set to 0 after local
>  password change we would disable not even cached log in but even off line
>  log in.
>  2) I could introduce SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN that would
>  behave as SYSDB_LAST_ONLINE_AUTH but could be set to 0 as proposed in 1) 
Having an extra attribute for this is a good idea and since we have to
read the user entry anyways and already write some updated attributes
back in the offline authentication code-path, it will have minimal extra
costs.

bye,
Sumit

>  >
>  >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).
>  Sure.
>  >
>  >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.
>  Yes, I agree that we must do that.
>  1) We could  just set SYSDB_LAST_ONLINE_AUTH (or
>  SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN) to 0 and require on line log in
>  next time.
>  2) Try online log in immediately. I suppose this is preferred because it
>  provides better user experience.
>  >
>  >>=== Authors ===
>  >>* Pavel Reichl <preichl(a)redhat.com&gt;
>  >>
>  >>_______________________________________________
>  >>sssd-devel mailing list
>  &gt;&gt;sssd-devel(a)lists.fedorahosted.org
>  >>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>  >_______________________________________________
>  >sssd-devel mailing list
>  &gt;sssd-devel(a)lists.fedorahosted.org
>  >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>  
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Pavel Reichl]

Hello,

thank you all for comments. I have updated the design page. You can find 
it there:

https://fedorahosted.org/sssd/wiki/DesignDocs/CachedAuthentication

I have also pasted it here.

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 login process may become 
inappropriately long, when servers are running under high workload (e.g. 
during classes, when many 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 
online authentication must be performed. Update PAM responder 
functionality for forwarding requests to domain providers by checking if 
request can be served from cache and if so execute same code branch as 
for offline authentication instead of contacting the domain provider.

If password is locally changed (via SSSD client) SSSD should use online 
authentication for the next login attempt.

SSSD should immediately try an online login if the password doesn't 
match while processing cached authentication. It will allow a user to 
correctly login if the password was changed through another client. (It 
will also make the server failed authentication counter go up if it was 
a password guessing attempt and it would also made such attempts to pay 
the full round trip to the server, which helps deter local attacks even 
if we do not do any other checks like we do for real offline 
authentication.)

=== Implementation details ===

* extend structure ''pam_auth_req''
  * add new field `use_cached_auth` (default value is false)
* extend structure ''sss_domain_info''
  * add new field `cached_authentication_timeout` which will hold value 
of newly introduced domain option `cached_authentication_timeout`
* introduce new sysdb attribute `SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN`
  * this attribute would mostly behave in the same way as 
`SYSDB_LAST_ONLINE_AUTH` but would be set to 0 when local password 
change happens
  * this would guarantee that after local password change, next login 
attempt won't be cached (if SSSD is in the online mode)
* extend ''pam_dom_forwarder()''
  * set local copy of `cached_authentication_timeout` to use the smaller 
of the domain's `cached_authentication_timeout` (given in seconds) and 
the `offline_credentials_expiration` (given in days, also must handle 
the special value 0 for offline_credentials_expiration)
  * do not forward request to a domain provider if
   * domain uses cached credentials ''AND''
   * (local) `cached_authentication_timeout` is greater than 0 ''AND''
   * last online login (resp. attribute 
`SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN`) of user who is being 
authenticated is not stale (> ''now()'' - (local) 
`cached_authentication_timeout`) ''AND''
   * PAM request can be handled from cache (PAM command is 
`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()''
* extend ''pam_handle_cached_login()''
  * if permission is denied and and cached authentication was used then 
return to ''pam_dom_forwarder()'' and perform online authentication
* introduce function ''sysdb_get_user_lastlogin_with_current_token()''
  * used to obtain value of attribute 
`SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN` for given user from sysdb 
while deciding in pam_dom_forwarder() whether authentication can be 
served from cache or domain provider must be contacted (no output to 
console should happen here)
* when password is being changed make sure that value of 
`SYSDB_LAST_ONLINE_AUTH_WITH_CURRENT_TOKEN` is set to 0

=== Configuration changes ===
A new domain option `cached_authentication_timeout` will be added. The 
value of this option is a time period in seconds for which cached 
authentication can be used. After this period is exceeded online 
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. test with correct password
  1. log in as user from domain which stores credentials and then log 
out and log in again. The second login should use cached credentials. 
Output should by similar to this, especially note the line starting 
with: '''Authenticated with cached credentials''' (Please note
that to 
see this console output ''pam_verbosity = 2'' must be set in pam section 
of sssd.conf.)
{{{
devel@dev $ su john
Password:
john@dev $ exit
devel@dev $ su john
Password:
Authenticated with cached credentials, your cached password will expire 
at: Wed 22 Apr 2015 08:47:29 AM EDT.
john@dev $
}}}
  1. for the `cached_authentication_timeout` seconds since the 1st login 
all subsequent login attempts (for the same user) should be served from 
cache and domain provider 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 online log in should be performed and new 
password must be used.
1. test with wrong password to check if:
  1. ''offline_failed_login_attempts'' is respected
  1. ''offline_failed_login_delay'' is respected
1. change locally password
  * verify that subsequent login attempt is processed online and that 
new password is accepted and old one is denied
1. change password directly on server or via another client then SSSD
  * verify that new password is accepted and that logs inform that 
cached authentication failed and online authentication had to be 
performed (please note that old password would be accepted as SSSD 
client has no knowledge that it was changed)

[Pavel Reichl]

On 05/04/2015 01:34 PM, Pavel Reichl wrote:
>  Hello,
>
>  thank you all for comments. I have updated the design page. You can 
>  find it there:
>
>  https://fedorahosted.org/sssd/wiki/DesignDocs/CachedAuthentication
>
>  I have also pasted it here.
>
>  Thanks! 
There was no activity in this thread for longer than a week so I assume 
I can commence the implementation.

Thanks all for comments.

[Pavel Reichl]

On 04/22/2015 11:09 AM, Sumit Bose wrote:
[snip]
>  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 
How exactly should be
offline_failed_login_attempts and 
offline_failed_login_delay respected?

In my current implementation cached authentication is  tried no matter 
the value of offline_failed_login_attempt.  If cached authentication 
fails offline_failed_login_attempt is increased and online 
authentication is tried. So currently offline_failed_login_delay has no 
influence for cached authentication. I don't consider this as as a 
security problem because online authentication is performed for every 
cached authentication attempt.
Do you agree?

>  (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.

[Pavel Reichl]

On 05/20/2015 04:51 PM, Pavel Reichl wrote:
>  On 04/22/2015 11:09 AM, Sumit Bose wrote:
>  [snip]
> > 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
>  How exactly should be offline_failed_login_attempts and 
>  offline_failed_login_delay respected?
>
>  In my current implementation cached authentication is  tried no matter 
>  the value of offline_failed_login_attempt.  If cached authentication 
>  fails offline_failed_login_attempt is increased and online 
>  authentication is tried. So currently offline_failed_login_delay has 
>  no influence for cached authentication. I don't consider this as as a 
>  security problem because online authentication is performed for every 
>  cached authentication attempt. 
Oh, sorry, correct wording should have been
"online authentication is 
performed for every *failed* cached authentication attempt"
>  Do you agree?
>
> > (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.
>
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Sumit Bose]

On Wed, May 20, 2015 at 04:54:41PM +0200, Pavel Reichl wrote:
>  
>  
>  On 05/20/2015 04:51 PM, Pavel Reichl wrote:
>  >
>  >
>  >On 04/22/2015 11:09 AM, Sumit Bose wrote:
>  >[snip]
>  >>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
>  >How exactly should be offline_failed_login_attempts and
>  >offline_failed_login_delay respected?
>  >
>  >In my current implementation cached authentication is  tried no matter the
>  >value of offline_failed_login_attempt.  If cached authentication fails
>  >offline_failed_login_attempt is increased and online authentication is
>  >tried. So currently offline_failed_login_delay has no influence for cached
>  >authentication. I don't consider this as as a security problem because
>  >online authentication is performed for every cached authentication
>  >attempt.
>  Oh, sorry, correct wording should have been "online authentication is
>  performed for every *failed* cached authentication attempt"
>  >Do you agree? 
yes, so the offline_* parameters are kept for real offline
authentication only. Would it be possible (without major changes) to not
increase offline_failed_login_attempts if cached authentication fails? 

bye,
Sumit

>  >
>  >>(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.
>  >
>  >_______________________________________________
>  >sssd-devel mailing list
>  >sssd-devel(a)lists.fedorahosted.org
>  >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>  
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Pavel Reichl]

On 05/28/2015 10:40 AM, Sumit Bose wrote:
>  On Wed, May 20, 2015 at 04:54:41PM +0200, Pavel Reichl wrote:
> >
> > On 05/20/2015 04:51 PM, Pavel Reichl wrote:
> >>
> >> On 04/22/2015 11:09 AM, Sumit Bose wrote:
> >> [snip]
> >>> 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
> >> How exactly should be offline_failed_login_attempts and
> >> offline_failed_login_delay respected?
> >>
> >> In my current implementation cached authentication is  tried no matter the
> >> value of offline_failed_login_attempt.  If cached authentication fails
> >> offline_failed_login_attempt is increased and online authentication is
> >> tried. So currently offline_failed_login_delay has no influence for cached
> >> authentication. I don't consider this as as a security problem because
> >> online authentication is performed for every cached authentication
> >> attempt.
> > Oh, sorry, correct wording should have been "online authentication is
> > performed for every *failed* cached authentication attempt"
> >> Do you agree?
>  yes, so the offline_* parameters are kept for real offline
>  authentication only. Would it be possible (without major changes) to not
>  increase offline_failed_login_attempts if cached authentication fails? 
Thanks for
the comment. I'm not sure how hard it will be. I'll look into 
it and do my best while addressing reviewers concerns with the first 
version of patches which is already on list.
>  bye,
>  Sumit
>
> >>> (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.
> >> _______________________________________________
> >> sssd-devel mailing list
> >> sssd-devel(a)lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel