Re: [Freeipa-devel] session authentication URI issues
On 12/22/2011 03:25 PM, Simo Sorce wrote: The WebUI uses /ipa/ui and /ipa/json The CLI uses only /ipa/xmlrpc In your whole discussion below you should rethink /ipa/rpc as /ipa/json because it looks to me you are only considering the WebUI client (that's just fine). Only because you conflated /ipa/json and /ipa/xmlrpc, treat them as separate things and it will be easier. Why can't we just keep /ipa/xmlrpc ? Why do you mix /ipa/json and /ipa/xmlrpc and call them the same and then propose to split them when they are separate from the start ? Sometimes you get too close to what you're working on and can't see the forest for the trees. Thank you for pointing out how /ipa/json and /ipa/xml are used exclusively and independently by the web UI and the command line tools respectively. How did I get confused? Those two URI's are treated identically in the existing code base, entry into the system via /ipa/json and /ipa/xml traverse the exact same code paths and hence I incorrectly conflated them. Sometimes it takes a second pair of eyes to see the obvious, thus this discussion was useful, thank you. I have recoded the logic in ipaserver/rpcserver.py to separate the two cases. I also had to refactor some of the logic surrounding when and where backend connections with their credentials are managed. The good news is both the web UI and the command line clients seem to be working fine with the new session based authentication. I have some clean-up work to do on the code before I prepare a patch for review. In particular I would like to do a better job of storing and setting the kerberos credentials than what I'm currently doing (currently more proof-of-concept than deployable robust code). We can have different URIs once we change the CLI, to maintain compatibility with old tools. But it would be the other way around. /ipa/xmlrpc would be krb protected by default and then we add /ipa/session/xmlrpc which is instead the session base one. Yes, once we implement session support in the command line clients we'll need a new URI (e.g /ipa/session/xmlrpc). I don't see anyway around that, but given the functionality is new that won't be an issue, everything remains backwards compatible. -- 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 authentication URI issues
On Wed, 2011-12-28 at 13:02 -0500, John Dennis wrote: On 12/22/2011 03:25 PM, Simo Sorce wrote: The WebUI uses /ipa/ui and /ipa/json The CLI uses only /ipa/xmlrpc In your whole discussion below you should rethink /ipa/rpc as /ipa/json because it looks to me you are only considering the WebUI client (that's just fine). Only because you conflated /ipa/json and /ipa/xmlrpc, treat them as separate things and it will be easier. Why can't we just keep /ipa/xmlrpc ? Why do you mix /ipa/json and /ipa/xmlrpc and call them the same and then propose to split them when they are separate from the start ? Sometimes you get too close to what you're working on and can't see the forest for the trees. Thank you for pointing out how /ipa/json and /ipa/xml are used exclusively and independently by the web UI and the command line tools respectively. How did I get confused? Those two URI's are treated identically in the existing code base, entry into the system via /ipa/json and /ipa/xml traverse the exact same code paths and hence I incorrectly conflated them. Sometimes it takes a second pair of eyes to see the obvious, thus this discussion was useful, thank you. I have recoded the logic in ipaserver/rpcserver.py to separate the two cases. I also had to refactor some of the logic surrounding when and where backend connections with their credentials are managed. The good news is both the web UI and the command line clients seem to be working fine with the new session based authentication. I have some clean-up work to do on the code before I prepare a patch for review. In particular I would like to do a better job of storing and setting the kerberos credentials than what I'm currently doing (currently more proof-of-concept than deployable robust code). Great news! Glad it was just a misunderstanding and not a hard to manage issue. We can have different URIs once we change the CLI, to maintain compatibility with old tools. But it would be the other way around. /ipa/xmlrpc would be krb protected by default and then we add /ipa/session/xmlrpc which is instead the session base one. Yes, once we implement session support in the command line clients we'll need a new URI (e.g /ipa/session/xmlrpc). I don't see anyway around that, but given the functionality is new that won't be an issue, everything remains backwards compatible. Yup, everything sounds nice and workable, thank you John. 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 authentication URI issues
On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote: For your holiday reading pleasure :-) Happy holidays to all. Ok, I want to try to restate the problem so that I'm sure I understand it. The way the session management is going to work is that the Apache server/FreeIPA application is going to kinit and get credentials on our behalf and store them in a session cache and provide us with a secure cookie. As long as we have that cookie, we have an access-key to the credential cache and apache can then use that to perform RPC requests in our name. When we connect via the CLI, we already have valid kerberos credentials, and we want to simply delegate those instead, so the Apache server doesn't need to maintain a session. What if we were to mandate that the FreeIPA server always allows issuing a TGT with a renewal time of no less than the TGT time? Then it would be possible to initiate a session by presenting our existing TGT to perform a renewal request on the apache server, which could then be cached into the session. We could then just use the session interface from then on, even in the CLI/libcurl. Is this doable? 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 authentication URI issues
On Thu, 2011-12-22 at 10:29 -0500, Stephen Gallagher wrote: On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote: For your holiday reading pleasure :-) Happy holidays to all. Ok, I want to try to restate the problem so that I'm sure I understand it. The way the session management is going to work is that the Apache server/FreeIPA application is going to kinit and get credentials on our behalf and store them in a session cache and provide us with a secure cookie. No. What you describe is the fallback mode used exclusively if you do not already have credentials and are redirected to a form based authentication page. In the normal case we use s4u2proxy to get a ticket on your behalf to the ldap server. We then store the whole credential cache in the session. As long as we have that cookie, we have an access-key to the credential cache and apache can then use that to perform RPC requests in our name. Yes. When we connect via the CLI, we already have valid kerberos credentials, and we want to simply delegate those instead, so the Apache server doesn't need to maintain a session. No. We want to use the same methods in the long term with the trick of storing the session cookie in the local cred cache so that CLI utils know where to find them. (We can also use a .ipa-cli file or the kernel keyring or something similar, we'll choose the most convenient compromise between reliability or security). However in the first implementation we can skip handling this for the CLI. What if we were to mandate that the FreeIPA server always allows issuing a TGT with a renewal time of no less than the TGT time? Then it would be possible to initiate a session by presenting our existing TGT to perform a renewal request on the apache server, which could then be cached into the session. We could then just use the session interface from then on, even in the CLI/libcurl. We do not want to give a TGT to the framwork. Is this doable? Yes but undesirable, and also unnecessary. 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 authentication URI issues
On 12/21/2011 02:07 PM, John Dennis wrote: For your holiday reading pleasure :-) Happy holidays to all. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel To answer a couple questions are almost certainly going to come up: When we first started discussing this a long while back, I looked in to what I still feel is the right long term solution, but whifch is not currently an option for release reasons. The most unified approach would extend mod_auth_krb to perform the caching of the credentials. A set of files that are Kerberos protected could have an additional specification that would stick the Credential in the session. This requires mod_auth_krb to know about mod_session. Unfortunately, due the versions of Apache and how we configure it, that does not work for IPA. Back porting mod_session to the version of Apache shipped with RHEL 6 is a non trivial undertaking. The IPA server runs with Apache in pre-fork mode, which means that each request is handled by a different process. Thus sessions, which depend on shared state, become a much heavier-weight proposal. In the future I would like to revisit this issue and attempt to integrate the change into mod_auth_krb. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
