Re: [Freeipa-devel] Session design document
On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: On 12/01/2011 08:48 PM, Simo Sorce wrote: On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. Can we please then extend the design to include this? Another approach (on Linux only) would be to have the CLI stuff the session key into the kernel keyring. It would be secure and would be capable of outliving the TGT life (if the session expiration is longer than the TGT expiration). signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Mon, 2011-12-05 at 09:42 -0500, Dmitri Pal wrote: On 12/05/2011 09:33 AM, Stephen Gallagher wrote: On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: On 12/01/2011 08:48 PM, Simo Sorce wrote: On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. Can we please then extend the design to include this? Another approach (on Linux only) would be to have the CLI stuff the session key into the kernel keyring. It would be secure and would be capable of outliving the TGT life (if the session expiration is longer than the TGT expiration). We support CLI only on Linux so this is not an issue. But it would not work cross multiple CLI commands as they are different processes and AFAIU only the process that put the data into the keyring would be able to fetch it unless we provide a special IPA shell that keeps one process and executes batch inside it. Am I wrong? Yes, you are wrong :) The keyring can be configured to be limited to either user or user and a specific process ID. We do the latter in SSSD, but that's a recent change. Previously we were restricting it only by user. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Fri, 02 Dec 2011, John Dennis wrote: My guess is we're not likely to be bumping up against the 1 MB per item threshold (nor would it be smart to anywhere be close to that). I think I recalled you mentioning that PAC data would max out around 16 KB. So I don't see the limit as being something we realistically need to worry about (or at least I hope not :-) According to http://support.microsoft.com/kb/327825: -- TokenSize = 1200 + 40d + 8s This formula uses the following values: d: The number of domain local groups a user is a member of plus the number of universal groups outside the user's account domain plus the number of groups represented in security ID (SID) history. s: The number of security global groups that a user is a member of plus the number of universal groups in a user's account domain. 1200: The estimated value for ticket overhead. This value can vary depending on factors such as DNS domain name length, client name, and other factors. --- The KB article goes on to say that the recommended maximum value is 65535 bytes. It is 'a fixed Kerberos ticket receive buffer that contains the SIDs that represent the groups in which the account is a member'. Thus, in large environments realistic limit is still 64Kb per PAC. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On 12/01/2011 08:48 PM, Simo Sorce wrote: On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. Can we please then extend the design to include this? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
Simo Sorce wrote: On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. The krb ccache will not be readable by ipa:ipa. You say that object sized for the stuff we will store in memcached should be limited. What is a reasonable size for those objects ? I was thinking we may want to store the krb ccaches in memcached in order to be able to keep them around. The reason I ask is that Krb ccaches can become quite big if PACs are attached to tickets although they are normally quite small. Aside for these minor details I totally agree with the direction you are proposing and I can't wait to see it implemented :) Yes, seems fine to me too. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. The krb ccache will not be readable by ipa:ipa. I feared that, although maybe we can do some trick with default ACLs to make them readable to the 'ipa' user. Do we have the option to re-implement SPNEGO in python and stop using mod_auth_kerb ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
Simo Sorce wrote: On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. The krb ccache will not be readable by ipa:ipa. I feared that, although maybe we can do some trick with default ACLs to make them readable to the 'ipa' user. Do we have the option to re-implement SPNEGO in python and stop using mod_auth_kerb ? Simo. We last looked at this way back in early v1 so it may be possible now, it wasn't then. This would be a long-term effort. Whatever we do we definitely don't want 389-ds to be running as the same user as the ipa framework. Breaking into the web server via our app would mean filesystem access to the raw LDAP database. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Fri, 2011-12-02 at 09:46 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. The krb ccache will not be readable by ipa:ipa. I feared that, although maybe we can do some trick with default ACLs to make them readable to the 'ipa' user. Do we have the option to re-implement SPNEGO in python and stop using mod_auth_kerb ? Simo. We last looked at this way back in early v1 so it may be possible now, it wasn't then. This would be a long-term effort. Yep, medium/long term. Whatever we do we definitely don't want 389-ds to be running as the same user as the ipa framework. Breaking into the web server via our app would mean filesystem access to the raw LDAP database. Totally agree, ipa:ipa should only be used for wsgi/memcached at most. Certainly not other services we currently have. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On 12/01/2011 09:55 PM, Simo Sorce wrote: On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. Thank you. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. You say that object sized for the stuff we will store in memcached should be limited. What is a reasonable size for those objects ? I was thinking we may want to store the krb ccaches in memcached in order to be able to keep them around. The reason I ask is that Krb ccaches can become quite big if PACs are attached to tickets although they are normally quite small. I had to do a little digging to get the answer. The maximum size of a single entry is 1 MB. That includes some metadata bound to the item for internal use, but it isn't a lot, so technically a single item's max size is just under one megabyte. This limit can be increased but the memcached developers do not recommend it (I believe because it reduces memory usage efficiency due to page hits). By default the memcached daemon initializes with 64 MB of total memory the vast majority of which is allocated to item storage and a minor amount allocated to bookkeeping. The total memory size is easily adjusted by a command line parameter when the daemon initializes. In addition the Python library supports compression using zlib. You specify a minimum compression length. The value is converted into it's storage form (python objects other than integers and strings are pickled) and if the length of the value in it's final storage form is greater than the minimum compression length zib is invoked to compress it. This way zlib compression is avoided for small items (or compression can be completely disabled). Thus we have the option to play around with compressing our entries if we discover we have some need to. I think initially we would disable compression sacrificing memory consumption in favor of performance. My guess is we're not likely to be bumping up against the 1 MB per item threshold (nor would it be smart to anywhere be close to that). I think I recalled you mentioning that PAC data would max out around 16 KB. So I don't see the limit as being something we realistically need to worry about (or at least I hope not :-) One nice feature of memcached is you can query the statistics from a live daemon at any time. While we're tuning we might need to do this. Aside for these minor details I totally agree with the direction you are proposing and I can't wait to see it implemented :) Simo. *In the long term we may even decide to stop using mod_auth_kerb and do our own handling if this simplifies things, but I guess we will need an interim transition period in any case, because we can't depend on too many changes to be done at once as a dependency to introduce sessions. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On 11/30/2011 05:33 PM, John Dennis wrote: ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: Comments? Suggestions? Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. You say that object sized for the stuff we will store in memcached should be limited. What is a reasonable size for those objects ? I was thinking we may want to store the krb ccaches in memcached in order to be able to keep them around. The reason I ask is that Krb ccaches can become quite big if PACs are attached to tickets although they are normally quite small. Aside for these minor details I totally agree with the direction you are proposing and I can't wait to see it implemented :) Simo. *In the long term we may even decide to stop using mod_auth_kerb and do our own handling if this simplifies things, but I guess we will need an interim transition period in any case, because we can't depend on too many changes to be done at once as a dependency to introduce sessions. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Session design document
-- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ [ Note: This document is formatted in restructuredText and may be viewed in HTML at this link: http://jdennis.fedorapeople.org/doc/ipa_session.html ] Session Support for IPA John Dennis jden...@redhat.com Goals = Provide per-user session data caching which persists between requests. Desired features are: * Integrates cleanly with minimum impact on existing infrastructure. * Provides maximum security balanced against real-world performance demands. * Sessions must be able to be revoked (flushed). * Should be flexible and easy to use for developers. * Should leverage existing technology and code to the maximum extent possible to avoid re-invention, excessive implementation time and to benefit from robustness in field proven components commonly shared in the open source community. * Must support multiple independent processes which share session data. * System must function correctly if session data is available or not. * Must be high performance. * Should not be tied to specific web servers or browsers. Should integrate with our chosen WSGI model. Issues == Cookies --- Most session implementations are based on the use of cookies. Cookies have some inherent problems. * User has the option to disable cookies. * User stored cookie data is not secure. Can be mitigated by setting flags indicating the cookie is only to be used with SSL secured HTTP connections to specific web resources and setting the cookie to expire at session termination. Most modern browsers enforce these. Where to store session data? Session data may be stored on either on the client or on the server. Storing session data on the client addresses the problem of session data availability when requests are serviced by independent web servers because the session data travels with the request. However there are data size limitations. Storing session data on the client also exposes sensitive data but this can be mitigated by encrypting the session data such that only the server can decrypt it. The more conventional approach is to bind session data to a unique name, the session ID. The session ID is transmitted to the client and the session data is paired with the session ID on the server in a associative data store. The session data is retrieved by the server using the session ID when the receiving the request. This eliminates exposing sensitive session data on the client along with limitations on data size. It however introduces the issue of session data availability when requests are serviced by more than one server process. Multi-process session data availability --- Apache (and other web servers) fork child processes to handle requests in parallel. Also web servers may be deployed in a farm where requests are load balanced in round robin fashion across different nodes. In both cases session data cannot be stored in the memory of a server process because it is not available to other processes, either sibling children of a master server process or server processes on distinct nodes. Typically this is addressed by storing session data in a SQL database. When a request is received by a server process containing a session ID in it's cookie data the session ID is used to perform a SQL query and the resulting data is then attached to the request as it proceeds through the request processing pipeline. This of course introduces coherency issues. For IPA the introduction of a SQL database dependency is undesired and should be avoided. Session data may also be shared by independent processes by storing the session data in files. An alternative solution which has gained considerable popularity recently is the use of a fast memory based caching server. Data is stored in a single process memory and may be queried and set via a light weight protocol using standard socket mechanisms, memcached is one example. A typical use is to optimize SQL queries by storing a SQL result in shared memory cache avoiding the more expensive SQL operation. But the memory cache has distinct advantages in non-SQL situations as well. Possible implementations for use by IPA === Apache Sessions --- Apache has 2.3 has implemented session support via these modules: mod_session Overarching session support based on cookies. See: http://httpd.apache.org/docs/2.3/mod/mod_session.html mod_session_cookie Stores session data in the client. See: http://httpd.apache.org/docs/2.3/mod/mod_session_cookie.html mod_session_crypto Encrypts session data for security. Encryption key is shared configuration parameter visible to all Apache processes and is stored in a configuration file. See: http://httpd.apache.org/docs/2.3/mod/mod_session_crypto.html mod_session_dbd Stores session data
