[Freeipa-devel] json/rpc from apache/java HttpClient

[Alexander Bokovoy]

On Mon, 08 Jun 2015, Timothy Worman wrote:
>On Jun 8, 2015, at 8:25 PM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
>>
>> On Mon, 08 Jun 2015, Timothy Worman wrote:
>>> I have developed a java client that is able to successfully commit
>>> transactions to FreeIPA using the json/rpc API. If it is useful, I
>>> could abstract all this and package it up to share. But I am seeing
>>> some interesting things - some of it may be my lack of experience using
>>> HttpClient but I wanted to run it by the list to see what should be
>>> expected.
>>>
>>> I have been following Alexander’s guidelines
>>> (https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions)
>>> to develop this.
>>>
>>> I am able to establish a kerberized connection to
>>> https://hostname/ipa/session/login_kerberos with the HttpClient,
>>> Krb5LoginModule, using AuthSchemes.SPNEGO, proper referer header, and
>>> jaas config. The connection is successful and I am caching the
>>> ipa-session cookie string for subsequent use (sending a second
>>> command). I am performing this as a PrivilegedAction.
>>>
>>> After successful authentication, I send a second transaction - a
>>> typical “list users” json formatted command to the server at
>>> https://hostname/ipa/json. I first attempted this without implementing
>>> PrivilegedAction since Alexander’s guide indicated I did NOT need to do
>>> any more authentication once  I had a session key. I added a cookie
>>> header to a plain https transaction with the session cookie. This did
>>> not work - which surprised me. The app actually prompted me at this
>>> point for login credentials. Any thoughts here?
>> You have to use session-enabled end point -- /ipa/session/json, not
>> normal one. I think my article points out this clearly.
>
>It probably does, and I probably missed it as people sometimes do. ;-) I will run some tests with this.
>
>> I decided to create a new PrivilegedAction class to send subsequent
>>> json transactions to the server. I moved my code for the 2nd connection
>>> in there. This works. But as a test, I commented out instructions to
>>> explicitly add the session cookie to the transaction. And it still
>>> works. I found that I do not explicitly have to add the cookie header.
>>> I am assuming that HttpClient natively handles cookies without explicit
>>> interaction.
>> Yes, HttpClient automatically parses cookies sent in responses and puts
>> them into a cookie store. Unless you are explicitly managing the cookie
>> store, the default is to use the same cookie store for all requests sent
>> associated with the client instance.
>>
>>> It does appear that I have a working client in any case.
>> Great!
>
>Yes. In further tests I’ve actually found I do not need the initial
>connection I spoke of. If I use HttpClient initialized as I described
>and simply post my json to https://hostname/ipa/json a connection is
>negotiated and the list users transaction appears to go through
>normally.
I've looked at the code. If you initialize session with Kerberos, you
can use either /ipa/session/json or /ipa/json because both rely on the
same cookie. The difference is in what happens when your session is
expired -- /ipa/session/json will redirect to the login page while
/ipa/json will just report a ccache error.


-- 
/ Alexander Bokovoy