<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 08/19/2011 02:17 PM, Stephen Gallagher wrote:
    <blockquote
      cite="mid:1313777873.4012.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">On Fri, 2011-08-19 at 14:07 -0400, Dmitri Pal wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I think you are wrong and there use cases when the timeout should be
different. But I will stop insisting.
And IMO if the auth can't go without the internal ID lookup is also
wrong. It should be an option to trust the auth server to do the right
thing and use id from cache.

</pre>
      </blockquote>
      <pre wrap="">
This is absolutely wrong. The reason for the forced ID lookup is because
you need to be sure that access-control rules are up-to-date. Those
access-control rules are not available to the auth server in many cases
(one such example is HBAC; consider a firewall issue or DS crash). It's
a security vulnerability to rely on online authentication and cached
access-control rules at the same time.

Other common examples would be classic LDAP/kerberos authentication
using either the simple access provider or pam_access. If the user's
group list has changed since the cache was updated, we could potentially
be granting access where it should now have been removed.

If the identity server is offline, we MUST work only with what we have
in the cache. This means using cached auth instead of online auth. (The
advantage here with Kerberos is that it means they aren't being granted
a TGT either).
</pre>
      <pre wrap="">
</pre>
    </blockquote>
    You are correct about the implications and by default we should what
    we do now. <br>
    But IMO it should be a choice with the current behavior as default.<br>
    The admin would need to assess the threat and implication of
    allowing access control checks against offline data.<br>
    Do not forget that this is how it has been done for years with local
    access.conf.<br>
    <br>
    It is good to direct people to the better choices and best practices
    but not to take the choices from them. In this case we try to
    "force" best practices which is good but we eventually need to be
    more flexible. <br>
    <br>
    Not a priority but is worth a "deferred" ticket...<br>
    <br>
    <br>
    <blockquote
      cite="mid:1313777873.4012.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/mailman/listinfo/sssd-devel">https://fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>