[Freeipa-devel] Talking json/rpc with java client

[Simo Sorce]

On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote:
> On Thu, 20 Mar 2014, Rob Crittenden wrote:
> >Alexander Bokovoy wrote:
> >>On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote:
> >>>On 03/18/2014 05:26 PM, Alexander Bokovoy wrote:
> >>>>On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote:
> >>>>>>>The difference between the two calls is on the last TGS_REQ;
> >>>>>>>because the first one is on ldap/olmo.example.com at EXAMPLE.COM and
> >>>>>>>it's OK whereas the second one is on
> >>>>>>>HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose).
> >>>>>>>
> >>>>>>>Where's the error?
> >>>>>>Am I correct that you have a user connecting to HTTP/ebano.example.com
> >>>>>>and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com
> >>>>>>using credentials of the user?
> >>>>>>
> >>>>>>FreeIPA uses constraint delegation of the credentials, with the
> >>>>>>help of
> >>>>>>S4U2Proxy extension. You need to allow HTTP/ebano.example.com to
> >>>>>>delegate
> >>>>>>credentials to HTTP/olmo.example.com.
> >>>>>>
> >>>>>>I have written an article how to do that:
> >>>>>>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Hi Alexander, thanks for your reply.
> >>>>>I read carefully your interesting post and I follow it to delegate
> >>>>>HTTP/ebano.example.com credentials to HTTP/olmo.example.com.
> >>>>>
> >>>>>Now, two questions:
> >>>>>1) How can I check that my configuration, now is ok? Because this
> >>>>>ldapsearch returns result: 0
> >>>>>
> >>>>>ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b
> >>>>>"cn=s4u2proxy,cn=etc,dc=example,dc=com"
> >>>>>"cn=ipa-http-delegation-targets" dn
> >>>>You need to create these delegation entries yourself, like the article
> >>>>says. Note that your app talks to IPA server's HTTP service, so create
> >>>>
> >>>>dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com
> >>>>objectClass: ipaKrb5DelegationACL
> >>>>objectClass: groupOfPrincipals
> >>>>objectClass: top
> >>>>cn: ebano-http-delegation
> >>>>memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM
> >>>>ipaAllowedTarget:
> >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
> >>>>
> >>>>This entry says: "HTTP/ebano.example.com is allowed to delegate users'
> >>>>credentials to whatever Kerberos principal is a member of
> >>>>cn=ebano-http-delegation-targets group"
> >>>>
> >>>>Now, this is the group:
> >>>>dn:
> >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
> >>>>objectClass: groupOfPrincipals
> >>>>objectClass: top
> >>>>cn: ebano-http-delegation-targets
> >>>>memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM
> >>>>
> >>>>With these two entries we would have HTTP/ebano.example.com allowed to
> >>>>delegate users' credentials to HTTP/olomo.example.com
> >>>
> >>>Hi Alexander, thanks for your patience.
> >>>I followed your suggestions but the result is always the same.
> >>>
> >>>Trying with curl, of course, it works.
> >>>
> >>>My doubt now is why curl generates this log on kerberos server
> >>>
> >>>mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1
> >>>etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18
> >>>tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM
> >>>mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
> >>>etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975,
> >>>etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for
> >>>ldap/olmo.example.com at EXAMPLE.COM
> >>This is effect of S4U extension working correctly.
> >>
> >>>whereas java generates this other one
> >>>
> >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes
> >>>{18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH:
> >>>HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM,
> >>>Additional pre-authentication required
> >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes
> >>>{18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes
> >>>{rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for
> >>>krbtgt/EXAMPLE.COM at EXAMPLE.COM
> >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
> >>>etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449,
> >>>etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for
> >>>HTTP/olmo.example.com at EXAMPLE.COM
> >>>
> >>>As you can see, the first one uses admin on ldap service, the second
> >>>one uses HTTP/ebano.example.com on HTTP service.
> >>This means your Java application doesn't use S4U extension or doesn't
> >>know about that.
> >>
> >>>Can I do the same call with Java?
> >>At this point we need to set clear what Java are you using.
> >>
> >>http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html
> >>
> >>tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8.
> >>
> >
> >The client doesn't do the S4U2Proxy work though, so this shouldn't 
> >matter, right?
> My point is that the client will not do what he expects unless S4U2Proxy
> is used in Java and that requires Java 8 platform, released on March
> 18th 2014.

I think you can use earlier Java versions but tell them to use the
native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in
the back for fun.

> That is, if there is a user talking to the Java client and
> then Java client turning to IPA LDAP or web server with constraint
> delegation.
> 
> This is something I tried to get clarification for in the original
> discussion.
> 
> 


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