You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Marco Di Sabatino Di Diodoro <ma...@tirasa.net> on 2014/03/14 17:53:57 UTC

CXF and kerberos authentication

Hi, 

I’m an PMC member of Apache Syncope[1].
We are building a new connector bundle for Connid[2] that needs to connect with FreeIpa server.

The connector bundle use JSON-RPC to communicate with the server that is protected by Kerberos.
We followed this guide (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the connector not negotiate with Kerberos

WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParameters());
AuthorizationPolicy policy = new AuthorizationPolicy();
policy.setAuthorizationType("Negotiate");
policy.setAuthorization(KEYTAB_CONF);
KerberosAuthOutInterceptor kbInterceptor = new KerberosAuthOutInterceptor();
kbInterceptor.setPolicy(policy);
kbInterceptor.setRealm(“EXAMPLE.COM");
kbInterceptor.setServicePrincipalName("ldap/olmo.example.com");
kbInterceptor.setCredDelegation(true);
WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);

I try a lot of other configuration without success, have you any suggestion?

If we run with curl it works.

Regards
M

[1] http://syncope.apache.org/
[2] http://tirasa.github.io/ConnId/

-- 
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/

Re: CXF and kerberos authentication

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

Sorry I got distracted when you asked on IRC.
As I said, I can only point at this stage to

https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/JAXRSKerberosBookTest.java;h=1a05eaa17ce405e2448efe952bd0c6e25d64ffc0;hb=HEAD

though I'd say your code is very similar.

Does the client fail immediately or you have a negotiate request 
rejected at the server ?
Can you post more info about the actual exception ?

It is always a bit challenging to set it up correctly. It is also 
possible that there's something in your environment that requires the 
additional changes to the interceptor, something that 'curl' does 
correctly.

Any chance you can compare say the complete service principal name, the 
way it is produced by curl and by CXF ?

Let us know please how you progress

Thanks, Sergey


On 14/03/14 16:53, Marco Di Sabatino Di Diodoro wrote:
> Hi,
>
> I’m an PMC member of Apache Syncope[1].
> We are building a new connector bundle for Connid[2] that needs to connect with FreeIpa server.
>
> The connector bundle use JSON-RPC to communicate with the server that is protected by Kerberos.
> We followed this guide (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the connector not negotiate with Kerberos
>
> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParameters());
> AuthorizationPolicy policy = new AuthorizationPolicy();
> policy.setAuthorizationType("Negotiate");
> policy.setAuthorization(KEYTAB_CONF);
> KerberosAuthOutInterceptor kbInterceptor = new KerberosAuthOutInterceptor();
> kbInterceptor.setPolicy(policy);
> kbInterceptor.setRealm(“EXAMPLE.COM");
> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com");
> kbInterceptor.setCredDelegation(true);
> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>
> I try a lot of other configuration without success, have you any suggestion?
>
> If we run with curl it works.
>
> Regards
> M
>
> [1] http://syncope.apache.org/
> [2] http://tirasa.github.io/ConnId/
>

Re: CXF and kerberos authentication

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi Marco,

Thanks for posting the logs below,
I think we can narrow down the issue to the following:

- the token created by CURL contains a permission to delegate on the 
server side
- the token created by CXF contains no such permission

It is something to do with the current process properties. This is my 
theory at least. Or with something very subtle.

You curl command line has no any Kerberos specific configuration, so I'm 
presuming, that when you run CURL, you as a root/etc has all the access 
rights to the default Kerberos store, right ?

I recall we had a user few weeks or so ago actually confirming the 
delegation works, though in that case a CXF server was extracting the 
token sent by the client and using it with the outbound client call...

Here is the relevant CXF code:

GSSManager manager = GSSManager.getInstance();
(1)
GSSName serverName = manager.createName(spn, null);

(2)
GSSCredential delegatedCred =
 
(GSSCredential)message.getContextualProperty(GSSCredential.class.getName());

         GSSContext context = manager
                 .createContext(serverName.canonicalize(oid), oid, 
delegatedCred, GSSContext.DEFAULT_LIFETIME);

(3)
         context.requestCredDeleg(isCredDelegationRequired(message));

         // If the delegated cred is not null then we only need the 
context to
         // immediately return a ticket based on this credential without 
attempting
         // to log on again
         return getToken(delegatedCred == null ? authPolicy : null,
                         context);

All CXF does (assuming delegatedCred is not set - as in your case) it 
requests the delegation if the user wants it to,
and then acquires a token, passing it the auth policy, in your case it 
is a KeyTab reference. And the token is acquited successfully but it has 
no delegation property set in it...

I'm not sure what to get out of it so far...
Please continue investigating.

What about enabling the Kerberos-level debug, that may show the way curl 
& CXF interacts with it ? May be the Java process has no enough 
privileges to enable the delegation ?

Thanks, Sergey

On 25/03/14 09:03, Marco Di Sabatino Di Diodoro wrote:
> Hi Sergey,
>
> Il giorno 19/mar/2014, alle ore 10:57, Sergey Beryozkin <sb...@gmail.com> ha scritto:
>
>> Hi Marco
>> On 19/03/14 08:44, Marco Di Sabatino Di Diodoro wrote:
>>> Hi Sergey
>>>
>>> thanks for your support.
>>> We asked the FreeIPA community to see if there are some incorrect configurations[1].
>>>
>>> I'll let you know when we have news.
>>>
>> Sounds good, thanks.
>>
>> What concerns me is the fact that using CURL to send Kerberos tokens to FreeIPA works, while using WebClient and Kerberos interceptor does not.
>> I suspect that something in the CXF code might need to be tweaked or may be it needs to be reconfigured a bit.
>> The logs you sent last time show that CXF manages to obtain a token but it is really a server which does not accept it. So I think CXF does correctly interacts with the Kerberos system, but what appears to be the case is that there is some difference in the way CXF and CURL send tokens.
>>
>> Can you please run CURL with -v option and see if you can spot something obvious, compared to the way CXF sends it ?
>
> these days, we are investigating why the call does not work with the java client.
> Our goal is to call a jsonrpc api protected from Kerberos. So we trying to call apache httpd with mod_auth_kerb. This is our cxf example [1].
>
> After cxf call, I noticed that httpd log has
>
> [Mon Mar 24 19:03:29.402055 2014] [auth_kerb:debug] [pid 10029] src/mod_auth_kerb.c(1724): [client 192.168.0.105:39499] Client didn't delegate us their credential, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.402084 2014] [auth_kerb:debug] [pid 10029] src/mod_auth_kerb.c(1743): [client 192.168.0.105:39499] GSS-API token of length 186 bytes will be sent back, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.402510 2014] [:info] [pid 10029] nss_hook_Auth
> [Mon Mar 24 19:03:29.402577 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of Require valid-user : granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.402676 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.403068 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of Require all granted: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.403172 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:03:29.403908 2014] [:error] [pid 10025] ipa: ERROR: 500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment
> [Mon Mar 24 19:03:29.404844 2014] [headers:debug] [pid 10029] mod_headers.c(845): AH01502: headers: ap_headers_output_filter()
>
> Whereas if I done the same call with curl on the httpd log there’s
>
> [Mon Mar 24 19:14:43.329966 2014] [auth_kerb:debug] [pid 10032] src/mod_auth_kerb.c(1724): [client 192.168.0.105:39504] Client delegated us their credential, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:43.329977 2014] [auth_kerb:debug] [pid 10032] src/mod_auth_kerb.c(1743): [client 192.168.0.105:39504] GSS-API token of length 156 bytes will be sent back, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:43.338700 2014] [:info] [pid 10032] nss_hook_Auth
> [Mon Mar 24 19:14:43.338721 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of Require valid-user : granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:43.338726 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:43.338878 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of Require all granted: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:43.338886 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
> [Mon Mar 24 19:14:44.371738 2014] [:error] [pid 10024] ipa: INFO: admin@TIRASA.NET: user_find(u'', all=u'true'): SUCCESS
> [Mon Mar 24 19:14:44.372957 2014] [headers:debug] [pid 10032] mod_headers.c(845): AH01502: headers: ap_headers_output_filter()
> [Mon Mar 24 19:14:44.375508 2014] [:info] [pid 10032] Connection to child 4 closed (server olmo.tirasa.net:443, client 192.168.0.105)
>
> Curl with -v option log:
>
> curl -v -H referer:https://olmo.tirasa.net/ipa -H "Content-Type:application/json" -H "Accept:applicaton/json" --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -d  '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' -X POST https://olmo.tirasa.net/ipa/json
>
> * Adding handle: conn: 0xc24ec0
> * Adding handle: send: 0
> * Adding handle: recv: 0
> * Curl_addHandleToPipeline: length: 1
> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
> * About to connect() to olmo.tirasa.net port 443 (#0)
> *   Trying 192.168.0.106...
> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> *   CAfile: /etc/ipa/ca.crt
>    CApath: none
> * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
> * Server certificate:
> * 	subject: CN=olmo.tirasa.net,O=TIRASA.NET
> * 	start date: mar 13 13:48:58 2014 GMT
> * 	expire date: mar 13 13:48:58 2016 GMT
> * 	common name: olmo.tirasa.net
> * 	issuer: CN=Certificate Authority,O=TIRASA.NET
>> POST /ipa/json HTTP/1.1
>> User-Agent: curl/7.32.0
>> Host: olmo.tirasa.net
>> referer:https://olmo.tirasa.net/ipa
>> Content-Type:application/json
>> Accept:applicaton/json
>> Content-Length: 60
>>
> * upload completely sent off: 60 out of 60 bytes
> < HTTP/1.1 401 Unauthorized
> < Date: Tue, 25 Mar 2014 08:17:15 GMT
> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted
> < Server: Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
> < WWW-Authenticate: Negotiate
> < Last-Modified: Tue, 28 Jan 2014 08:12:54 GMT
> < Accept-Ranges: bytes
> < Content-Length: 1383
> < Content-Type: text/html; charset=UTF-8
> <
> * Ignoring the response-body
> * Connection #0 to host olmo.tirasa.net left intact
> * Issue another request to this URL: 'https://olmo.tirasa.net/ipa/json'
> * Found bundle for host olmo.tirasa.net: 0xc258a0
> * Re-using existing connection! (#0) with host olmo.tirasa.net
> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
> * Adding handle: conn: 0xc24ec0
> * Adding handle: send: 0
> * Adding handle: recv: 0
> * Curl_addHandleToPipeline: length: 1
> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
> * Server auth using GSS-Negotiate with user ''
>> POST /ipa/json HTTP/1.1
>> Authorization: Negotiate YIIE8QYJKoZIhvcSAQICAQBuggTgMIIE3KADAgEFoQMCAQ6iBwMFACAAAACjggFVYYIBUTCCAU2gAwIBBaEMGwpUSVJBU0EuTkVUoiIwIKADAgEBoRkwFxsESFRUUBsPb2xtby50aXJhc2EubmV0o4IBEjCCAQ6gAwIBEqEDAgECooIBAASB/fM6eW0p4pD8wvFfwNLF5R5wq5jjmY4nSCij5Ijom2SFhtxB7GYHIHGmU7/obmkKG2zqW/a7Uw85fLh+lkZJ+z1WjBwNswAOBIQ7+9NaHcOJXGttuyToiqCuUdfm6RndbrZ1e7heIsS9CajEACmOiY5T7hJa2Ld8chN6xHLhbJlqTmcFcRRwHNDA/ehxgGe5xXQg7NZd4LSWbRjsDdS/NlmxY3EPVHZhLn0MCG/sG+b2favQbn9tTfEOU3S5zK47eUNC39e25sN6WkGImGL2d90G0vgnpGFW/DXcqEWH8+wXaVL4fzTR93wkzk56hLhtYvxmjDxOer/6/kXR4z2kggNsMIIDaKADAgESooIDXwSCA1vo49R1NgVJXKb4nhEZAMggkNY+S2SmMgb3m/cc7Hkq6kb+Jz8ClM51SjV5eUYI70dYbp/e8FoZwq5irwfG+s4KKRkhCZX5y8t6cOewU2cp++7J8M8G6GHOw7sm+TOdAQfwsVPWqgHhw69Ih7W48inYazDkyJfr4k9+Vu3IZxjyJBlaF6idV5w8cFK0LuSVrUDtk74MJ+mM08jE0wWONqHcoWD/xYklShavDb0bOvEm7TfvBKYuwsrsGl4ubgphvWcd+DnT/dFjtx583GbiqgSDSbHUEC93C9DIcxnUwqbsMWKDohtsG1dTZp/JfX3yQdoa/lfyn32fIPyP7ucwZWN/hy3JUgizI6WdVR+2z3lqSCG3WIzVAQLYek+SZbQ4gmhOl6SydF7sYlqAjSNoBHSTxB610+pIak/uR2qrqa
 2
VPWlsX8aAKaYrlPSVyckxtTb1G/OFahIZJPA0m/CIYJjFF0E/TnhmkwdPaIHQ5miOVwxDMUL1dBQXO9w1gwCcvbLrt3N43Ogo6DlOGj3Ticst9gZMBXeDPwrnOufB5FZBWtksc9fonyZRyq70c7GOrShwVjqlpG4toZcLRba0kCpggjxmV45o+AedpV9I9fYP8tDV619e1EtDGGKnsSfiRzINqFYA8jlKpSTjVPZNqTPh140bsmqDRQtvSRNfb7ftlLfF+lI7UmCeJB31d6CUQkqr4MV7PO7zAMjji8DSzPgzpjnYAi2Re+kzbJmllEzUQarFMKM9VEmpCO0Q3SKcM64Rw5qRajFwaduQ2oPCe1Mrws++jtxHDvXtm77Rc0NM30uJcriauCj5XYbfMPHnbqHFa+iFB3OtedbU+HAtth2S0IC/47LgoV0GnVLZWU18P0LTtQwiyJ6p/pRpUiMJB8LwjV8eKsZOSnJDFCXN3ulOuC/xEV4/eumQPg9Eq/eYdQH8xoGCUVKiriEfJD9eilYe+fZWJOfwSgHGiddVZqBoAsALjr/snkF8O0oCP2d0YxrBb/xpbLexXEhLw84FtKtthZGsIfEB5JLpeWj/7FDNj3AHWSYq2qg2ajB87p6VTw+eSEspdmPCbn/mzo/IrVr0Iv3RD3tIodcqKWY/sr/VU2YjBKGj/zVbYxOgRf8DohuqOZ4Qglo4dmUi
>> User-Agent: curl/7.32.0
>> Host: olmo.tirasa.net
>> referer:https://olmo.tirasa.net/ipa
>> Content-Type:application/json
>> Accept:applicaton/json
>> Content-Length: 60
>>
> * upload completely sent off: 60 out of 60 bytes
> < HTTP/1.1 200 Success
> < Date: Tue, 25 Mar 2014 08:17:15 GMT
> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted
> < Server: Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
> < WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvc4GoDMzW+ZiPr3J9m2XX/cQl2kVjQBeSNfBy89lI/xnvdDcEArVUOTNJeaKKaGR4W/Tv0op0ZUsVw8M7UHu+tmndta9kYG4WAORN6RHGPL4ww8br/oFtCUAcretWQzkfeOMMHrYjQfvFl3GkjUJs
> < Vary: Accept-Encoding
> < Transfer-Encoding: chunked
> < Content-Type: application/json; charset=utf-8
> <
> {
>      "error": null,
>      "id": 0,
>      "principal": "admin@TIRASA.NET",
>      "result": {
>          "count": 1,
>          "messages": [
>              {
>                  "code": 13001,
>                  "message": "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.65",
>                  "name": "VersionMissing",
>                  "type": "warning"
>              }
>          ],
>          "result": [
>              {
>                  "cn": [
>                      "Administrator"
>                  ],
>                  "dn": "uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net",
>                  "gecos": [
>                      "Administrator"
>                  ],
>                  "gidnumber": [
>                      "163600000"
>                  ],
>                  "has_keytab": true,
>                  "has_password": true,
>                  "homedirectory": [
>                      "/home/admin"
>                  ],
>                  "ipauniqueid": [
>                      "a524777e-aab5-11e3-bd11-080027e7a744"
>                  ],
>                  "krbextradata": [
>                      {
>                          "__base64__": "AALItyFTcm9vdC9hZG1pbkBUSVJBU0EuTkVUAA=="
>                      }
>                  ],
>                  "krblastpwdchange": [
>                      "20140313135104Z"
>                  ],
>                  "krblastsuccessfulauth": [
>                      "20140325081717Z"
>                  ],
>                  "krbpasswordexpiration": [
>                      "20140611135104Z"
>                  ],
>                  "krbprincipalname": [
>                      "admin@TIRASA.NET"
>                  ],
>                  "loginshell": [
>                      "/bin/bash"
>                  ],
>                  "memberof_group": [
>                      "admins",
>                      "trust admins"
>                  ],
>                  "nsaccountlock": false,
>                  "objectclass": [
>                      "top",
>                      "person",
>                      "posixaccount",
>                      "krbprincipalaux",
>                      "krbticketpolicyaux",
>                      "inetuser",
>                      "ipaobject",
>                      "ipasshuser",
>                      "ipaSshGroupOfPubKeys"
>                  ],
>                  "sn": [
>                      "Administrator"
>                  ],
>                  "uid": [
>                      "admin"
>                  ],
>                  "uidnumber": [
>                      "163600000"
>                  ]
>              }
>          ],
>          "summary": "1 user matched",
>          "truncated": false
>      },
>      "version": "3.3.4"
> * Connection #0 to host olmo.tirasa.net left intact
>
> What do you think? Any suggestions?
> M
>
> [1] https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/tirasa/kerberosexample/CXFClient.java
>
>>
>> Thanks, Sergey
>>
>>
>>
>>> Thanks
>>> M
>>>
>>> [1] https://www.redhat.com/archives/freeipa-devel/2014-March/msg00296.html
>>>
>>> Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin <sb...@gmail.com> ha scritto:
>>>
>>>> Hi
>>>> How do you configure it with curl ?
>>>> In your opinion, what is the difference between the way you set it up in curl and in CXF ?
>>>>
>>>> Cheers, Sergey
>>>>
>>>>
>>>>
>>>> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
>>>>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>>>>>
>>>>>> Hi Marco,
>>>>>>
>>>>>> I would suggest to try simple Kerberos login using JAAS directly (with
>>>>>> debug=true), perhaps it helps to spot the problem:
>>>>>>
>>>>>> Test code:
>>>>>>        URL conf =
>>>>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>>>>>        System.setProperty("java.security.auth.login.config",
>>>>>> conf.toString());
>>>>>>
>>>>>>        // Only needed when not using the ticket cache
>>>>>>        CallbackHandler callbackHandler = new CallbackHandler() {
>>>>>>
>>>>>>            @Override
>>>>>>            public void handle(Callback[] callbacks) throws
>>>>>> IOException, UnsupportedCallbackException {
>>>>>>                for (Callback callback : callbacks) {
>>>>>>                    if (callback instanceof NameCallback) {
>>>>>>                        ((NameCallback)callback).setName("alice");
>>>>>>                    }
>>>>>>                    if (callback instanceof PasswordCallback) {
>>>>>>                        ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>>>>>                    }
>>>>>>                }
>>>>>>
>>>>>>            }
>>>>>>        };
>>>>>>
>>>>>>        try {
>>>>>>            LoginContext lc = new LoginContext("myContext",
>>>>>> callbackHandler);
>>>>>>            lc.login();
>>>>>>            Subject subject = lc.getSubject();
>>>>>>            Set<Principal> principals = subject.getPrincipals();
>>>>>>            Set<Object> credentials = subject.getPrivateCredentials();
>>>>>>            System.out.println("OK: " + principals);
>>>>>>            System.out.println("OK: " + credentials);
>>>>>>        } catch (LoginException e) {
>>>>>>            e.printStackTrace();
>>>>>>        }
>>>>>>    }
>>>>>>
>>>>>> Jaas.conf:
>>>>>>
>>>>>> myContext {
>>>>>>    com.sun.security.auth.module.Krb5LoginModule required
>>>>>>    debug=true
>>>>>>    refreshKrb5Config=true
>>>>>>    useKeyTab=true
>>>>>>    storeKey=true
>>>>>>    keyTab="my.keytab"
>>>>>>    principal="my/services.example.com <http://services.example.com>";
>>>>>> };
>>>>>>
>>>>>> If the code works, you will be able to detect what is different with
>>>>>> AbstractSpnegoAuthSupplier.getToken() code used from
>>>>>> KerberosAuthOutInterceptor.java.
>>>>>
>>>>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>>>>>
>>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
>>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>> krbtgt/TIRASA.NET@TIRASA.NET <ma...@TIRASA.NET>
>>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
>>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>>>
>>>>> If we run with curl:
>>>>>
>>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
>>>>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET
>>>>> <ma...@TIRASA.NET> for krbtgt/TIRASA.NET@TIRASA.NET
>>>>> <ma...@TIRASA.NET>
>>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
>>>>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
>>>>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>>>
>>>>> I have attached the log file of the test connector. As you can see from
>>>>> the log, at the beginning we make a login and after a request to the
>>>>> service, but returns a 401.
>>>>>
>>>>> Thanks
>>>>> M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Andrei.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>>>>>>> Sent: Freitag, 14. März 2014 17:54
>>>>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>>>>>> Subject: CXF and kerberos authentication
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm an PMC member of Apache Syncope[1].
>>>>>>> We are building a new connector bundle for Connid[2] that needs to
>>>>>>> connect
>>>>>>> with FreeIpa server.
>>>>>>>
>>>>>>> The connector bundle use JSON-RPC to communicate with the server that is
>>>>>>> protected by Kerberos.
>>>>>>> We followed this guide
>>>>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>>>>>> connector not negotiate with Kerberos
>>>>>>>
>>>>>>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>>>>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>>>>>>> eters());
>>>>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>>>>>> policy.setAuthorizationType("Negotiate");
>>>>>>> policy.setAuthorization(KEYTAB_CONF);
>>>>>>> KerberosAuthOutInterceptor kbInterceptor = new
>>>>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>>>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>>>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>>>>>> <http://olmo.example.com>");
>>>>>>> kbInterceptor.setCredDelegation(true);
>>>>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>>>>>
>>>>>>> I try a lot of other configuration without success, have you any
>>>>>>> suggestion?
>>>>>>>
>>>>>>> If we run with curl it works.
>>>>>>>
>>>>>>> Regards
>>>>>>> M
>>>>>>>
>>>>>>> [1] http://syncope.apache.org/
>>>>>>> [2] http://tirasa.github.io/ConnId/
>>>>>>>
>>>>>>> --
>>>>>>> Dott. Marco Di Sabatino Di Diodoro
>>>>>>> Tel. +39 3939065570
>>>>>>>
>>>>>>> Tirasa S.r.l.
>>>>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>>>>> http://www.tirasa.net
>>>>>>>
>>>>>>> Apache Syncope PMC Member
>>>>>>> http://people.apache.org/~mdisabatino/
>>>>>>
>>>>>
>>>>> --
>>>>> Dott. Marco Di Sabatino Di Diodoro
>>>>> Tel. +39 3939065570
>>>>>
>>>>> Tirasa S.r.l.
>>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>>> http://www.tirasa.net <http://www.tirasa.net/>
>>>>>
>>>>> Apache Syncope PMC Member
>>>>> http://people.apache.org/~mdisabatino/
>>>>>
>>>>
>>>
>>
>

Re: CXF and kerberos authentication

Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.

Il giorno 25/mar/2014, alle ore 14:47, Andrei Shakirin <as...@talend.com> ha scritto:

> Hi Marco,
> 
> Curios, does distilled java JAAS Kerberos call throw the same error?

Login works for both. 
The problem is in the next step, when it has to delegate.

> 
>        URL conf = JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>        System.setProperty("java.security.auth.login.config", conf.toString());
> 
>        try {
>            LoginContext lc = new LoginContext("myContext", callbackHandler);
>            lc.login();
>            Subject subject = lc.getSubject();
>            Set<Principal> principals = subject.getPrincipals();
>            Set<Object> credentials = subject.getPrivateCredentials();
>            System.out.println("OK: " + principals);
>            System.out.println("OK: " + credentials);
>        } catch (LoginException e) {
>            e.printStackTrace();
>        }
>    }
> 
> Jaas.conf:
> 
> myContext {
>    com.sun.security.auth.module.Krb5LoginModule required
>    debug=true
>    refreshKrb5Config=true
>    useKeyTab=true
>    storeKey=true
>    keyTab="my.keytab"
>    principal="my/services.example.com";
> };
> 
> Regards,
> Andrei.

Regards
Marco

> 
>> -----Original Message-----
>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>> Sent: Dienstag, 25. März 2014 10:04
>> To: users@cxf.apache.org
>> Subject: Re: CXF and kerberos authentication
>> 
>> Hi Sergey,
>> 
>> Il giorno 19/mar/2014, alle ore 10:57, Sergey Beryozkin
>> <sb...@gmail.com> ha scritto:
>> 
>>> Hi Marco
>>> On 19/03/14 08:44, Marco Di Sabatino Di Diodoro wrote:
>>>> Hi Sergey
>>>> 
>>>> thanks for your support.
>>>> We asked the FreeIPA community to see if there are some incorrect
>> configurations[1].
>>>> 
>>>> I'll let you know when we have news.
>>>> 
>>> Sounds good, thanks.
>>> 
>>> What concerns me is the fact that using CURL to send Kerberos tokens to
>> FreeIPA works, while using WebClient and Kerberos interceptor does not.
>>> I suspect that something in the CXF code might need to be tweaked or may be
>> it needs to be reconfigured a bit.
>>> The logs you sent last time show that CXF manages to obtain a token but it is
>> really a server which does not accept it. So I think CXF does correctly interacts
>> with the Kerberos system, but what appears to be the case is that there is some
>> difference in the way CXF and CURL send tokens.
>>> 
>>> Can you please run CURL with -v option and see if you can spot something
>> obvious, compared to the way CXF sends it ?
>> 
>> these days, we are investigating why the call does not work with the java client.
>> Our goal is to call a jsonrpc api protected from Kerberos. So we trying to call
>> apache httpd with mod_auth_kerb. This is our cxf example [1].
>> 
>> After cxf call, I noticed that httpd log has
>> 
>> [Mon Mar 24 19:03:29.402055 2014] [auth_kerb:debug] [pid 10029]
>> src/mod_auth_kerb.c(1724): [client 192.168.0.105:39499] Client didn't delegate
>> us their credential, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
>> 19:03:29.402084 2014] [auth_kerb:debug] [pid 10029]
>> src/mod_auth_kerb.c(1743): [client 192.168.0.105:39499] GSS-API token of
>> length 186 bytes will be sent back, referer: https://olmo.tirasa.net/ipa [Mon
>> Mar 24 19:03:29.402510 2014] [:info] [pid 10029] nss_hook_Auth [Mon Mar 24
>> 19:03:29.402577 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802):
>> [client 192.168.0.105:39499] AH01626: authorization result of Require valid-
>> user : granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
>> 19:03:29.402676 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802):
>> [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>:
>> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403068
>> 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client
>> 192.168.0.105:39499] AH01626: authorization result of Require all granted:
>> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403172
>> 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client
>> 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted,
>> referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403908 2014]
>> [:error] [pid 10025] ipa: ERROR: 500 Internal Server Error:
>> jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request
>> environment [Mon Mar 24 19:03:29.404844 2014] [headers:debug] [pid 10029]
>> mod_headers.c(845): AH01502: headers: ap_headers_output_filter()
>> 
>> Whereas if I done the same call with curl on the httpd log there's
>> 
>> [Mon Mar 24 19:14:43.329966 2014] [auth_kerb:debug] [pid 10032]
>> src/mod_auth_kerb.c(1724): [client 192.168.0.105:39504] Client delegated us
>> their credential, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
>> 19:14:43.329977 2014] [auth_kerb:debug] [pid 10032]
>> src/mod_auth_kerb.c(1743): [client 192.168.0.105:39504] GSS-API token of
>> length 156 bytes will be sent back, referer: https://olmo.tirasa.net/ipa [Mon
>> Mar 24 19:14:43.338700 2014] [:info] [pid 10032] nss_hook_Auth [Mon Mar 24
>> 19:14:43.338721 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802):
>> [client 192.168.0.105:39504] AH01626: authorization result of Require valid-
>> user : granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
>> 19:14:43.338726 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802):
>> [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>:
>> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:43.338878
>> 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client
>> 192.168.0.105:39504] AH01626: authorization result of Require all granted:
>> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:43.338886
>> 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client
>> 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted,
>> referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:44.371738 2014]
>> [:error] [pid 10024] ipa: INFO: admin@TIRASA.NET: user_find(u'', all=u'true'):
>> SUCCESS [Mon Mar 24 19:14:44.372957 2014] [headers:debug] [pid 10032]
>> mod_headers.c(845): AH01502: headers: ap_headers_output_filter() [Mon Mar
>> 24 19:14:44.375508 2014] [:info] [pid 10032] Connection to child 4 closed
>> (server olmo.tirasa.net:443, client 192.168.0.105)
>> 
>> Curl with -v option log:
>> 
>> curl -v -H referer:https://olmo.tirasa.net/ipa -H "Content-Type:application/json"
>> -H "Accept:applicaton/json" --negotiate -u : --delegation always --cacert
>> /etc/ipa/ca.crt -d  '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' -
>> X POST https://olmo.tirasa.net/ipa/json
>> 
>> * Adding handle: conn: 0xc24ec0
>> * Adding handle: send: 0
>> * Adding handle: recv: 0
>> * Curl_addHandleToPipeline: length: 1
>> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
>> * About to connect() to olmo.tirasa.net port 443 (#0)
>> *   Trying 192.168.0.106...
>> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
>> * Initializing NSS with certpath: sql:/etc/pki/nssdb
>> *   CAfile: /etc/ipa/ca.crt
>>  CApath: none
>> * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
>> * Server certificate:
>> * 	subject: CN=olmo.tirasa.net,O=TIRASA.NET
>> * 	start date: mar 13 13:48:58 2014 GMT
>> * 	expire date: mar 13 13:48:58 2016 GMT
>> * 	common name: olmo.tirasa.net
>> * 	issuer: CN=Certificate Authority,O=TIRASA.NET
>>> POST /ipa/json HTTP/1.1
>>> User-Agent: curl/7.32.0
>>> Host: olmo.tirasa.net
>>> referer:https://olmo.tirasa.net/ipa
>>> Content-Type:application/json
>>> Accept:applicaton/json
>>> Content-Length: 60
>>> 
>> * upload completely sent off: 60 out of 60 bytes < HTTP/1.1 401 Unauthorized <
>> Date: Tue, 25 Mar 2014 08:17:15 GMT
>> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3
>> Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted < Server: Apache/2.4.7
>> (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC
>> mod_wsgi/3.4 Python/2.7.5 < WWW-Authenticate: Negotiate < Last-Modified:
>> Tue, 28 Jan 2014 08:12:54 GMT < Accept-Ranges: bytes < Content-Length: 1383
>> < Content-Type: text/html; charset=UTF-8 <
>> * Ignoring the response-body
>> * Connection #0 to host olmo.tirasa.net left intact
>> * Issue another request to this URL: 'https://olmo.tirasa.net/ipa/json'
>> * Found bundle for host olmo.tirasa.net: 0xc258a0
>> * Re-using existing connection! (#0) with host olmo.tirasa.net
>> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
>> * Adding handle: conn: 0xc24ec0
>> * Adding handle: send: 0
>> * Adding handle: recv: 0
>> * Curl_addHandleToPipeline: length: 1
>> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
>> * Server auth using GSS-Negotiate with user ''
>>> POST /ipa/json HTTP/1.1
>>> Authorization: Negotiate
>>> 
>> YIIE8QYJKoZIhvcSAQICAQBuggTgMIIE3KADAgEFoQMCAQ6iBwMFACAAAACjggF
>> VYYIBUT
>>> 
>> CCAU2gAwIBBaEMGwpUSVJBU0EuTkVUoiIwIKADAgEBoRkwFxsESFRUUBsPb2xtb
>> y50aXJh
>>> 
>> c2EubmV0o4IBEjCCAQ6gAwIBEqEDAgECooIBAASB/fM6eW0p4pD8wvFfwNLF5R
>> 5wq5jjmY
>>> 
>> 4nSCij5Ijom2SFhtxB7GYHIHGmU7/obmkKG2zqW/a7Uw85fLh+lkZJ+z1WjBwNsw
>> AOBIQ7
>>> 
>> +9NaHcOJXGttuyToiqCuUdfm6RndbrZ1e7heIsS9CajEACmOiY5T7hJa2Ld8chN6x
>> HLhbJ
>>> 
>> lqTmcFcRRwHNDA/ehxgGe5xXQg7NZd4LSWbRjsDdS/NlmxY3EPVHZhLn0MCG/s
>> G+b2favQ
>>> 
>> bn9tTfEOU3S5zK47eUNC39e25sN6WkGImGL2d90G0vgnpGFW/DXcqEWH8+wXa
>> VL4fzTR93
>>> 
>> wkzk56hLhtYvxmjDxOer/6/kXR4z2kggNsMIIDaKADAgESooIDXwSCA1vo49R1NgV
>> JXKb4
>>> 
>> nhEZAMggkNY+S2SmMgb3m/cc7Hkq6kb+Jz8ClM51SjV5eUYI70dYbp/e8FoZwq5i
>> rwfG+s
>>> 
>> 4KKRkhCZX5y8t6cOewU2cp++7J8M8G6GHOw7sm+TOdAQfwsVPWqgHhw69Ih7
>> W48inYazDk
>>> 
>> yJfr4k9+Vu3IZxjyJBlaF6idV5w8cFK0LuSVrUDtk74MJ+mM08jE0wWONqHcoWD/x
>> YklSh
>>> 
>> avDb0bOvEm7TfvBKYuwsrsGl4ubgphvWcd+DnT/dFjtx583GbiqgSDSbHUEC93C9
>> DIcxnU
>>> 
>> wqbsMWKDohtsG1dTZp/JfX3yQdoa/lfyn32fIPyP7ucwZWN/hy3JUgizI6WdVR+2z3
>> lqSC
>>> 
>> G3WIzVAQLYek+SZbQ4gmhOl6SydF7sYlqAjSNoBHSTxB610+pIak/uR2qrqa2VPWl
>> sX8aA
>>> 
>> KaYrlPSVyckxtTb1G/OFahIZJPA0m/CIYJjFF0E/TnhmkwdPaIHQ5miOVwxDMUL1d
>> BQXO9
>>> 
>> w1gwCcvbLrt3N43Ogo6DlOGj3Ticst9gZMBXeDPwrnOufB5FZBWtksc9fonyZRyq7
>> 0c7GO
>>> 
>> rShwVjqlpG4toZcLRba0kCpggjxmV45o+AedpV9I9fYP8tDV619e1EtDGGKnsSfiRzI
>> NqF
>>> 
>> YA8jlKpSTjVPZNqTPh140bsmqDRQtvSRNfb7ftlLfF+lI7UmCeJB31d6CUQkqr4MV7
>> PO7z
>>> 
>> AMjji8DSzPgzpjnYAi2Re+kzbJmllEzUQarFMKM9VEmpCO0Q3SKcM64Rw5qRajF
>> waduQ2o
>>> 
>> PCe1Mrws++jtxHDvXtm77Rc0NM30uJcriauCj5XYbfMPHnbqHFa+iFB3OtedbU+H
>> Atth2S
>>> 
>> 0IC/47LgoV0GnVLZWU18P0LTtQwiyJ6p/pRpUiMJB8LwjV8eKsZOSnJDFCXN3ulOu
>> C/xEV
>>> 
>> 4/eumQPg9Eq/eYdQH8xoGCUVKiriEfJD9eilYe+fZWJOfwSgHGiddVZqBoAsALjr/s
>> nkF8
>>> 
>> O0oCP2d0YxrBb/xpbLexXEhLw84FtKtthZGsIfEB5JLpeWj/7FDNj3AHWSYq2qg2ajB
>> 87p
>>> 
>> 6VTw+eSEspdmPCbn/mzo/IrVr0Iv3RD3tIodcqKWY/sr/VU2YjBKGj/zVbYxOgRf8D
>> ohuq
>>> OZ4Qglo4dmUi
>>> User-Agent: curl/7.32.0
>>> Host: olmo.tirasa.net
>>> referer:https://olmo.tirasa.net/ipa
>>> Content-Type:application/json
>>> Accept:applicaton/json
>>> Content-Length: 60
>>> 
>> * upload completely sent off: 60 out of 60 bytes < HTTP/1.1 200 Success < Date:
>> Tue, 25 Mar 2014 08:17:15 GMT
>> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3
>> Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted < Server: Apache/2.4.7
>> (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC
>> mod_wsgi/3.4 Python/2.7.5 < WWW-Authenticate: Negotiate
>> YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvc4G
>> oDMzW+ZiPr3J9m2XX/cQl2kVjQBeSNfBy89lI/xnvdDcEArVUOTNJeaKKaGR4W/T
>> v0op0ZUsVw8M7UHu+tmndta9kYG4WAORN6RHGPL4ww8br/oFtCUAcretWQzkf
>> eOMMHrYjQfvFl3GkjUJs
>> < Vary: Accept-Encoding
>> < Transfer-Encoding: chunked
>> < Content-Type: application/json; charset=utf-8 < {
>>    "error": null,
>>    "id": 0,
>>    "principal": "admin@TIRASA.NET",
>>    "result": {
>>        "count": 1,
>>        "messages": [
>>            {
>>                "code": 13001,
>>                "message": "API Version number was not sent, forward compatibility
>> not guaranteed. Assuming server's API version, 2.65",
>>                "name": "VersionMissing",
>>                "type": "warning"
>>            }
>>        ],
>>        "result": [
>>            {
>>                "cn": [
>>                    "Administrator"
>>                ],
>>                "dn": "uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net",
>>                "gecos": [
>>                    "Administrator"
>>                ],
>>                "gidnumber": [
>>                    "163600000"
>>                ],
>>                "has_keytab": true,
>>                "has_password": true,
>>                "homedirectory": [
>>                    "/home/admin"
>>                ],
>>                "ipauniqueid": [
>>                    "a524777e-aab5-11e3-bd11-080027e7a744"
>>                ],
>>                "krbextradata": [
>>                    {
>>                        "__base64__":
>> "AALItyFTcm9vdC9hZG1pbkBUSVJBU0EuTkVUAA=="
>>                    }
>>                ],
>>                "krblastpwdchange": [
>>                    "20140313135104Z"
>>                ],
>>                "krblastsuccessfulauth": [
>>                    "20140325081717Z"
>>                ],
>>                "krbpasswordexpiration": [
>>                    "20140611135104Z"
>>                ],
>>                "krbprincipalname": [
>>                    "admin@TIRASA.NET"
>>                ],
>>                "loginshell": [
>>                    "/bin/bash"
>>                ],
>>                "memberof_group": [
>>                    "admins",
>>                    "trust admins"
>>                ],
>>                "nsaccountlock": false,
>>                "objectclass": [
>>                    "top",
>>                    "person",
>>                    "posixaccount",
>>                    "krbprincipalaux",
>>                    "krbticketpolicyaux",
>>                    "inetuser",
>>                    "ipaobject",
>>                    "ipasshuser",
>>                    "ipaSshGroupOfPubKeys"
>>                ],
>>                "sn": [
>>                    "Administrator"
>>                ],
>>                "uid": [
>>                    "admin"
>>                ],
>>                "uidnumber": [
>>                    "163600000"
>>                ]
>>            }
>>        ],
>>        "summary": "1 user matched",
>>        "truncated": false
>>    },
>>    "version": "3.3.4"
>> * Connection #0 to host olmo.tirasa.net left intact
>> 
>> What do you think? Any suggestions?
>> M
>> 
>> [1]
>> https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/t
>> irasa/kerberosexample/CXFClient.java
>> 
>>> 
>>> Thanks, Sergey
>>> 
>>> 
>>> 
>>>> Thanks
>>>> M
>>>> 
>>>> [1]
>>>> https://www.redhat.com/archives/freeipa-devel/2014-
>> March/msg00296.htm
>>>> l
>>>> 
>>>> Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin
>> <sb...@gmail.com> ha scritto:
>>>> 
>>>>> Hi
>>>>> How do you configure it with curl ?
>>>>> In your opinion, what is the difference between the way you set it up in curl
>> and in CXF ?
>>>>> 
>>>>> Cheers, Sergey
>>>>> 
>>>>> 
>>>>> 
>>>>> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
>>>>>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>>>>>> 
>>>>>>> Hi Marco,
>>>>>>> 
>>>>>>> I would suggest to try simple Kerberos login using JAAS directly
>>>>>>> (with debug=true), perhaps it helps to spot the problem:
>>>>>>> 
>>>>>>> Test code:
>>>>>>>      URL conf =
>>>>>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>>>>>>      System.setProperty("java.security.auth.login.config",
>>>>>>> conf.toString());
>>>>>>> 
>>>>>>>      // Only needed when not using the ticket cache
>>>>>>>      CallbackHandler callbackHandler = new CallbackHandler() {
>>>>>>> 
>>>>>>>          @Override
>>>>>>>          public void handle(Callback[] callbacks) throws
>>>>>>> IOException, UnsupportedCallbackException {
>>>>>>>              for (Callback callback : callbacks) {
>>>>>>>                  if (callback instanceof NameCallback) {
>>>>>>>                      ((NameCallback)callback).setName("alice");
>>>>>>>                  }
>>>>>>>                  if (callback instanceof PasswordCallback) {
>>>>>>> 
>> ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>>>>>>                  }
>>>>>>>              }
>>>>>>> 
>>>>>>>          }
>>>>>>>      };
>>>>>>> 
>>>>>>>      try {
>>>>>>>          LoginContext lc = new LoginContext("myContext",
>>>>>>> callbackHandler);
>>>>>>>          lc.login();
>>>>>>>          Subject subject = lc.getSubject();
>>>>>>>          Set<Principal> principals = subject.getPrincipals();
>>>>>>>          Set<Object> credentials = subject.getPrivateCredentials();
>>>>>>>          System.out.println("OK: " + principals);
>>>>>>>          System.out.println("OK: " + credentials);
>>>>>>>      } catch (LoginException e) {
>>>>>>>          e.printStackTrace();
>>>>>>>      }
>>>>>>>  }
>>>>>>> 
>>>>>>> Jaas.conf:
>>>>>>> 
>>>>>>> myContext {
>>>>>>>  com.sun.security.auth.module.Krb5LoginModule required
>>>>>>>  debug=true
>>>>>>>  refreshKrb5Config=true
>>>>>>>  useKeyTab=true
>>>>>>>  storeKey=true
>>>>>>>  keyTab="my.keytab"
>>>>>>>  principal="my/services.example.com
>>>>>>> <http://services.example.com>"; };
>>>>>>> 
>>>>>>> If the code works, you will be able to detect what is different
>>>>>>> with
>>>>>>> AbstractSpnegoAuthSupplier.getToken() code used from
>>>>>>> KerberosAuthOutInterceptor.java.
>>>>>> 
>>>>>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>>>>>> 
>>>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
>>>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>>> krbtgt/TIRASA.NET@TIRASA.NET
>> <ma...@TIRASA.NET>
>>>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
>>>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>>> ldap/olmo.tirasa.net@TIRASA.NET
>>>>>> <ma...@TIRASA.NET>
>>>>>> 
>>>>>> If we run with curl:
>>>>>> 
>>>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
>>>>>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18},
>>>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>>> krbtgt/TIRASA.NET@TIRASA.NET
>> <ma...@TIRASA.NET>
>>>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
>>>>>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
>>>>>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>>>> ldap/olmo.tirasa.net@TIRASA.NET
>>>>>> <ma...@TIRASA.NET>
>>>>>> 
>>>>>> I have attached the log file of the test connector. As you can see
>>>>>> from the log, at the beginning we make a login and after a request
>>>>>> to the service, but returns a 401.
>>>>>> 
>>>>>> Thanks
>>>>>> M
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Andrei.
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Marco Di Sabatino Di Diodoro
>>>>>>>> [mailto:marco.disabatino@tirasa.net]
>>>>>>>> Sent: Freitag, 14. März 2014 17:54
>>>>>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>>>>>>> Subject: CXF and kerberos authentication
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I'm an PMC member of Apache Syncope[1].
>>>>>>>> We are building a new connector bundle for Connid[2] that needs
>>>>>>>> to connect with FreeIpa server.
>>>>>>>> 
>>>>>>>> The connector bundle use JSON-RPC to communicate with the server
>>>>>>>> that is protected by Kerberos.
>>>>>>>> We followed this guide
>>>>>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>>>>>>> connector not negotiate with Kerberos
>>>>>>>> 
>>>>>>>> WebClient wc =
>>>>>>>> WebClient.create("https://olmo.example.com/ipa/json");
>>>>>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(c
>>>>>>>> lientParam
>>>>>>>> eters());
>>>>>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>>>>>>> policy.setAuthorizationType("Negotiate");
>>>>>>>> policy.setAuthorization(KEYTAB_CONF);
>>>>>>>> KerberosAuthOutInterceptor kbInterceptor = new
>>>>>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>>>>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>>>>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>>>>>>> <http://olmo.example.com>");
>>>>>>>> kbInterceptor.setCredDelegation(true);
>>>>>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>>>>>> 
>>>>>>>> I try a lot of other configuration without success, have you any
>>>>>>>> suggestion?
>>>>>>>> 
>>>>>>>> If we run with curl it works.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> M
>>>>>>>> 
>>>>>>>> [1] http://syncope.apache.org/
>>>>>>>> [2] http://tirasa.github.io/ConnId/
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570
>>>>>>>> 
>>>>>>>> Tirasa S.r.l.
>>>>>>>> Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39
>>>>>>>> 0859111173 http://www.tirasa.net
>>>>>>>> 
>>>>>>>> Apache Syncope PMC Member
>>>>>>>> http://people.apache.org/~mdisabatino/
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Dott. Marco Di Sabatino Di Diodoro
>>>>>> Tel. +39 3939065570
>>>>>> 
>>>>>> Tirasa S.r.l.
>>>>>> Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39
>>>>>> 0859111173 http://www.tirasa.net <http://www.tirasa.net/>
>>>>>> 
>>>>>> Apache Syncope PMC Member
>>>>>> http://people.apache.org/~mdisabatino/
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> --
>> Dott. Marco Di Sabatino Di Diodoro
>> Tel. +39 3939065570
>> 
>> Tirasa S.r.l.
>> Viale D'Annunzio 267 - 65127 Pescara
>> Tel +39 0859116307 / FAX +39 0859111173
>> http://www.tirasa.net
>> 
>> Apache Syncope PMC Member
>> http://people.apache.org/~mdisabatino/
> 

-- 
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/

RE: CXF and kerberos authentication

Posted by Andrei Shakirin <as...@talend.com>.

Hi Marco,

Curios, does distilled java JAAS Kerberos call throw the same error?

        URL conf = JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
        System.setProperty("java.security.auth.login.config", conf.toString());

        try {
            LoginContext lc = new LoginContext("myContext", callbackHandler);
            lc.login();
            Subject subject = lc.getSubject();
            Set<Principal> principals = subject.getPrincipals();
            Set<Object> credentials = subject.getPrivateCredentials();
            System.out.println("OK: " + principals);
            System.out.println("OK: " + credentials);
        } catch (LoginException e) {
            e.printStackTrace();
        }
    }

Jaas.conf:

myContext {
    com.sun.security.auth.module.Krb5LoginModule required
    debug=true
    refreshKrb5Config=true
    useKeyTab=true
    storeKey=true
    keyTab="my.keytab"
    principal="my/services.example.com";
};

Regards,
Andrei.

> -----Original Message-----
> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
> Sent: Dienstag, 25. März 2014 10:04
> To: users@cxf.apache.org
> Subject: Re: CXF and kerberos authentication
> 
> Hi Sergey,
> 
> Il giorno 19/mar/2014, alle ore 10:57, Sergey Beryozkin
> <sb...@gmail.com> ha scritto:
> 
> > Hi Marco
> > On 19/03/14 08:44, Marco Di Sabatino Di Diodoro wrote:
> >> Hi Sergey
> >>
> >> thanks for your support.
> >> We asked the FreeIPA community to see if there are some incorrect
> configurations[1].
> >>
> >> I'll let you know when we have news.
> >>
> > Sounds good, thanks.
> >
> > What concerns me is the fact that using CURL to send Kerberos tokens to
> FreeIPA works, while using WebClient and Kerberos interceptor does not.
> > I suspect that something in the CXF code might need to be tweaked or may be
> it needs to be reconfigured a bit.
> > The logs you sent last time show that CXF manages to obtain a token but it is
> really a server which does not accept it. So I think CXF does correctly interacts
> with the Kerberos system, but what appears to be the case is that there is some
> difference in the way CXF and CURL send tokens.
> >
> > Can you please run CURL with -v option and see if you can spot something
> obvious, compared to the way CXF sends it ?
> 
> these days, we are investigating why the call does not work with the java client.
> Our goal is to call a jsonrpc api protected from Kerberos. So we trying to call
> apache httpd with mod_auth_kerb. This is our cxf example [1].
> 
> After cxf call, I noticed that httpd log has
> 
> [Mon Mar 24 19:03:29.402055 2014] [auth_kerb:debug] [pid 10029]
> src/mod_auth_kerb.c(1724): [client 192.168.0.105:39499] Client didn't delegate
> us their credential, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
> 19:03:29.402084 2014] [auth_kerb:debug] [pid 10029]
> src/mod_auth_kerb.c(1743): [client 192.168.0.105:39499] GSS-API token of
> length 186 bytes will be sent back, referer: https://olmo.tirasa.net/ipa [Mon
> Mar 24 19:03:29.402510 2014] [:info] [pid 10029] nss_hook_Auth [Mon Mar 24
> 19:03:29.402577 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802):
> [client 192.168.0.105:39499] AH01626: authorization result of Require valid-
> user : granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
> 19:03:29.402676 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802):
> [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>:
> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403068
> 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client
> 192.168.0.105:39499] AH01626: authorization result of Require all granted:
> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403172
> 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client
> 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted,
> referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:03:29.403908 2014]
> [:error] [pid 10025] ipa: ERROR: 500 Internal Server Error:
> jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request
> environment [Mon Mar 24 19:03:29.404844 2014] [headers:debug] [pid 10029]
> mod_headers.c(845): AH01502: headers: ap_headers_output_filter()
> 
> Whereas if I done the same call with curl on the httpd log there's
> 
> [Mon Mar 24 19:14:43.329966 2014] [auth_kerb:debug] [pid 10032]
> src/mod_auth_kerb.c(1724): [client 192.168.0.105:39504] Client delegated us
> their credential, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
> 19:14:43.329977 2014] [auth_kerb:debug] [pid 10032]
> src/mod_auth_kerb.c(1743): [client 192.168.0.105:39504] GSS-API token of
> length 156 bytes will be sent back, referer: https://olmo.tirasa.net/ipa [Mon
> Mar 24 19:14:43.338700 2014] [:info] [pid 10032] nss_hook_Auth [Mon Mar 24
> 19:14:43.338721 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802):
> [client 192.168.0.105:39504] AH01626: authorization result of Require valid-
> user : granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24
> 19:14:43.338726 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802):
> [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>:
> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:43.338878
> 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client
> 192.168.0.105:39504] AH01626: authorization result of Require all granted:
> granted, referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:43.338886
> 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client
> 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted,
> referer: https://olmo.tirasa.net/ipa [Mon Mar 24 19:14:44.371738 2014]
> [:error] [pid 10024] ipa: INFO: admin@TIRASA.NET: user_find(u'', all=u'true'):
> SUCCESS [Mon Mar 24 19:14:44.372957 2014] [headers:debug] [pid 10032]
> mod_headers.c(845): AH01502: headers: ap_headers_output_filter() [Mon Mar
> 24 19:14:44.375508 2014] [:info] [pid 10032] Connection to child 4 closed
> (server olmo.tirasa.net:443, client 192.168.0.105)
> 
> Curl with -v option log:
> 
> curl -v -H referer:https://olmo.tirasa.net/ipa -H "Content-Type:application/json"
> -H "Accept:applicaton/json" --negotiate -u : --delegation always --cacert
> /etc/ipa/ca.crt -d  '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' -
> X POST https://olmo.tirasa.net/ipa/json
> 
> * Adding handle: conn: 0xc24ec0
> * Adding handle: send: 0
> * Adding handle: recv: 0
> * Curl_addHandleToPipeline: length: 1
> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
> * About to connect() to olmo.tirasa.net port 443 (#0)
> *   Trying 192.168.0.106...
> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> *   CAfile: /etc/ipa/ca.crt
>   CApath: none
> * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
> * Server certificate:
> * 	subject: CN=olmo.tirasa.net,O=TIRASA.NET
> * 	start date: mar 13 13:48:58 2014 GMT
> * 	expire date: mar 13 13:48:58 2016 GMT
> * 	common name: olmo.tirasa.net
> * 	issuer: CN=Certificate Authority,O=TIRASA.NET
> > POST /ipa/json HTTP/1.1
> > User-Agent: curl/7.32.0
> > Host: olmo.tirasa.net
> > referer:https://olmo.tirasa.net/ipa
> > Content-Type:application/json
> > Accept:applicaton/json
> > Content-Length: 60
> >
> * upload completely sent off: 60 out of 60 bytes < HTTP/1.1 401 Unauthorized <
> Date: Tue, 25 Mar 2014 08:17:15 GMT
> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3
> Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted < Server: Apache/2.4.7
> (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC
> mod_wsgi/3.4 Python/2.7.5 < WWW-Authenticate: Negotiate < Last-Modified:
> Tue, 28 Jan 2014 08:12:54 GMT < Accept-Ranges: bytes < Content-Length: 1383
> < Content-Type: text/html; charset=UTF-8 <
> * Ignoring the response-body
> * Connection #0 to host olmo.tirasa.net left intact
> * Issue another request to this URL: 'https://olmo.tirasa.net/ipa/json'
> * Found bundle for host olmo.tirasa.net: 0xc258a0
> * Re-using existing connection! (#0) with host olmo.tirasa.net
> * Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
> * Adding handle: conn: 0xc24ec0
> * Adding handle: send: 0
> * Adding handle: recv: 0
> * Curl_addHandleToPipeline: length: 1
> * - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
> * Server auth using GSS-Negotiate with user ''
> > POST /ipa/json HTTP/1.1
> > Authorization: Negotiate
> >
> YIIE8QYJKoZIhvcSAQICAQBuggTgMIIE3KADAgEFoQMCAQ6iBwMFACAAAACjggF
> VYYIBUT
> >
> CCAU2gAwIBBaEMGwpUSVJBU0EuTkVUoiIwIKADAgEBoRkwFxsESFRUUBsPb2xtb
> y50aXJh
> >
> c2EubmV0o4IBEjCCAQ6gAwIBEqEDAgECooIBAASB/fM6eW0p4pD8wvFfwNLF5R
> 5wq5jjmY
> >
> 4nSCij5Ijom2SFhtxB7GYHIHGmU7/obmkKG2zqW/a7Uw85fLh+lkZJ+z1WjBwNsw
> AOBIQ7
> >
> +9NaHcOJXGttuyToiqCuUdfm6RndbrZ1e7heIsS9CajEACmOiY5T7hJa2Ld8chN6x
> HLhbJ
> >
> lqTmcFcRRwHNDA/ehxgGe5xXQg7NZd4LSWbRjsDdS/NlmxY3EPVHZhLn0MCG/s
> G+b2favQ
> >
> bn9tTfEOU3S5zK47eUNC39e25sN6WkGImGL2d90G0vgnpGFW/DXcqEWH8+wXa
> VL4fzTR93
> >
> wkzk56hLhtYvxmjDxOer/6/kXR4z2kggNsMIIDaKADAgESooIDXwSCA1vo49R1NgV
> JXKb4
> >
> nhEZAMggkNY+S2SmMgb3m/cc7Hkq6kb+Jz8ClM51SjV5eUYI70dYbp/e8FoZwq5i
> rwfG+s
> >
> 4KKRkhCZX5y8t6cOewU2cp++7J8M8G6GHOw7sm+TOdAQfwsVPWqgHhw69Ih7
> W48inYazDk
> >
> yJfr4k9+Vu3IZxjyJBlaF6idV5w8cFK0LuSVrUDtk74MJ+mM08jE0wWONqHcoWD/x
> YklSh
> >
> avDb0bOvEm7TfvBKYuwsrsGl4ubgphvWcd+DnT/dFjtx583GbiqgSDSbHUEC93C9
> DIcxnU
> >
> wqbsMWKDohtsG1dTZp/JfX3yQdoa/lfyn32fIPyP7ucwZWN/hy3JUgizI6WdVR+2z3
> lqSC
> >
> G3WIzVAQLYek+SZbQ4gmhOl6SydF7sYlqAjSNoBHSTxB610+pIak/uR2qrqa2VPWl
> sX8aA
> >
> KaYrlPSVyckxtTb1G/OFahIZJPA0m/CIYJjFF0E/TnhmkwdPaIHQ5miOVwxDMUL1d
> BQXO9
> >
> w1gwCcvbLrt3N43Ogo6DlOGj3Ticst9gZMBXeDPwrnOufB5FZBWtksc9fonyZRyq7
> 0c7GO
> >
> rShwVjqlpG4toZcLRba0kCpggjxmV45o+AedpV9I9fYP8tDV619e1EtDGGKnsSfiRzI
> NqF
> >
> YA8jlKpSTjVPZNqTPh140bsmqDRQtvSRNfb7ftlLfF+lI7UmCeJB31d6CUQkqr4MV7
> PO7z
> >
> AMjji8DSzPgzpjnYAi2Re+kzbJmllEzUQarFMKM9VEmpCO0Q3SKcM64Rw5qRajF
> waduQ2o
> >
> PCe1Mrws++jtxHDvXtm77Rc0NM30uJcriauCj5XYbfMPHnbqHFa+iFB3OtedbU+H
> Atth2S
> >
> 0IC/47LgoV0GnVLZWU18P0LTtQwiyJ6p/pRpUiMJB8LwjV8eKsZOSnJDFCXN3ulOu
> C/xEV
> >
> 4/eumQPg9Eq/eYdQH8xoGCUVKiriEfJD9eilYe+fZWJOfwSgHGiddVZqBoAsALjr/s
> nkF8
> >
> O0oCP2d0YxrBb/xpbLexXEhLw84FtKtthZGsIfEB5JLpeWj/7FDNj3AHWSYq2qg2ajB
> 87p
> >
> 6VTw+eSEspdmPCbn/mzo/IrVr0Iv3RD3tIodcqKWY/sr/VU2YjBKGj/zVbYxOgRf8D
> ohuq
> > OZ4Qglo4dmUi
> > User-Agent: curl/7.32.0
> > Host: olmo.tirasa.net
> > referer:https://olmo.tirasa.net/ipa
> > Content-Type:application/json
> > Accept:applicaton/json
> > Content-Length: 60
> >
> * upload completely sent off: 60 out of 60 bytes < HTTP/1.1 200 Success < Date:
> Tue, 25 Mar 2014 08:17:15 GMT
> * Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3
> Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted < Server: Apache/2.4.7
> (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC
> mod_wsgi/3.4 Python/2.7.5 < WWW-Authenticate: Negotiate
> YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvc4G
> oDMzW+ZiPr3J9m2XX/cQl2kVjQBeSNfBy89lI/xnvdDcEArVUOTNJeaKKaGR4W/T
> v0op0ZUsVw8M7UHu+tmndta9kYG4WAORN6RHGPL4ww8br/oFtCUAcretWQzkf
> eOMMHrYjQfvFl3GkjUJs
> < Vary: Accept-Encoding
> < Transfer-Encoding: chunked
> < Content-Type: application/json; charset=utf-8 < {
>     "error": null,
>     "id": 0,
>     "principal": "admin@TIRASA.NET",
>     "result": {
>         "count": 1,
>         "messages": [
>             {
>                 "code": 13001,
>                 "message": "API Version number was not sent, forward compatibility
> not guaranteed. Assuming server's API version, 2.65",
>                 "name": "VersionMissing",
>                 "type": "warning"
>             }
>         ],
>         "result": [
>             {
>                 "cn": [
>                     "Administrator"
>                 ],
>                 "dn": "uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net",
>                 "gecos": [
>                     "Administrator"
>                 ],
>                 "gidnumber": [
>                     "163600000"
>                 ],
>                 "has_keytab": true,
>                 "has_password": true,
>                 "homedirectory": [
>                     "/home/admin"
>                 ],
>                 "ipauniqueid": [
>                     "a524777e-aab5-11e3-bd11-080027e7a744"
>                 ],
>                 "krbextradata": [
>                     {
>                         "__base64__":
> "AALItyFTcm9vdC9hZG1pbkBUSVJBU0EuTkVUAA=="
>                     }
>                 ],
>                 "krblastpwdchange": [
>                     "20140313135104Z"
>                 ],
>                 "krblastsuccessfulauth": [
>                     "20140325081717Z"
>                 ],
>                 "krbpasswordexpiration": [
>                     "20140611135104Z"
>                 ],
>                 "krbprincipalname": [
>                     "admin@TIRASA.NET"
>                 ],
>                 "loginshell": [
>                     "/bin/bash"
>                 ],
>                 "memberof_group": [
>                     "admins",
>                     "trust admins"
>                 ],
>                 "nsaccountlock": false,
>                 "objectclass": [
>                     "top",
>                     "person",
>                     "posixaccount",
>                     "krbprincipalaux",
>                     "krbticketpolicyaux",
>                     "inetuser",
>                     "ipaobject",
>                     "ipasshuser",
>                     "ipaSshGroupOfPubKeys"
>                 ],
>                 "sn": [
>                     "Administrator"
>                 ],
>                 "uid": [
>                     "admin"
>                 ],
>                 "uidnumber": [
>                     "163600000"
>                 ]
>             }
>         ],
>         "summary": "1 user matched",
>         "truncated": false
>     },
>     "version": "3.3.4"
> * Connection #0 to host olmo.tirasa.net left intact
> 
> What do you think? Any suggestions?
> M
> 
> [1]
> https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/t
> irasa/kerberosexample/CXFClient.java
> 
> >
> > Thanks, Sergey
> >
> >
> >
> >> Thanks
> >> M
> >>
> >> [1]
> >> https://www.redhat.com/archives/freeipa-devel/2014-
> March/msg00296.htm
> >> l
> >>
> >> Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin
> <sb...@gmail.com> ha scritto:
> >>
> >>> Hi
> >>> How do you configure it with curl ?
> >>> In your opinion, what is the difference between the way you set it up in curl
> and in CXF ?
> >>>
> >>> Cheers, Sergey
> >>>
> >>>
> >>>
> >>> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
> >>>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
> >>>>
> >>>>> Hi Marco,
> >>>>>
> >>>>> I would suggest to try simple Kerberos login using JAAS directly
> >>>>> (with debug=true), perhaps it helps to spot the problem:
> >>>>>
> >>>>> Test code:
> >>>>>       URL conf =
> >>>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
> >>>>>       System.setProperty("java.security.auth.login.config",
> >>>>> conf.toString());
> >>>>>
> >>>>>       // Only needed when not using the ticket cache
> >>>>>       CallbackHandler callbackHandler = new CallbackHandler() {
> >>>>>
> >>>>>           @Override
> >>>>>           public void handle(Callback[] callbacks) throws
> >>>>> IOException, UnsupportedCallbackException {
> >>>>>               for (Callback callback : callbacks) {
> >>>>>                   if (callback instanceof NameCallback) {
> >>>>>                       ((NameCallback)callback).setName("alice");
> >>>>>                   }
> >>>>>                   if (callback instanceof PasswordCallback) {
> >>>>>
> ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
> >>>>>                   }
> >>>>>               }
> >>>>>
> >>>>>           }
> >>>>>       };
> >>>>>
> >>>>>       try {
> >>>>>           LoginContext lc = new LoginContext("myContext",
> >>>>> callbackHandler);
> >>>>>           lc.login();
> >>>>>           Subject subject = lc.getSubject();
> >>>>>           Set<Principal> principals = subject.getPrincipals();
> >>>>>           Set<Object> credentials = subject.getPrivateCredentials();
> >>>>>           System.out.println("OK: " + principals);
> >>>>>           System.out.println("OK: " + credentials);
> >>>>>       } catch (LoginException e) {
> >>>>>           e.printStackTrace();
> >>>>>       }
> >>>>>   }
> >>>>>
> >>>>> Jaas.conf:
> >>>>>
> >>>>> myContext {
> >>>>>   com.sun.security.auth.module.Krb5LoginModule required
> >>>>>   debug=true
> >>>>>   refreshKrb5Config=true
> >>>>>   useKeyTab=true
> >>>>>   storeKey=true
> >>>>>   keyTab="my.keytab"
> >>>>>   principal="my/services.example.com
> >>>>> <http://services.example.com>"; };
> >>>>>
> >>>>> If the code works, you will be able to detect what is different
> >>>>> with
> >>>>> AbstractSpnegoAuthSupplier.getToken() code used from
> >>>>> KerberosAuthOutInterceptor.java.
> >>>>
> >>>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
> >>>>
> >>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
> >>>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
> >>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
> >>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
> >>>> krbtgt/TIRASA.NET@TIRASA.NET
> <ma...@TIRASA.NET>
> >>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
> >>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
> >>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
> >>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
> >>>> ldap/olmo.tirasa.net@TIRASA.NET
> >>>> <ma...@TIRASA.NET>
> >>>>
> >>>> If we run with curl:
> >>>>
> >>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
> >>>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
> >>>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18},
> >>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
> >>>> krbtgt/TIRASA.NET@TIRASA.NET
> <ma...@TIRASA.NET>
> >>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
> >>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
> >>>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
> >>>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
> >>>> ldap/olmo.tirasa.net@TIRASA.NET
> >>>> <ma...@TIRASA.NET>
> >>>>
> >>>> I have attached the log file of the test connector. As you can see
> >>>> from the log, at the beginning we make a login and after a request
> >>>> to the service, but returns a 401.
> >>>>
> >>>> Thanks
> >>>> M
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Andrei.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Marco Di Sabatino Di Diodoro
> >>>>>> [mailto:marco.disabatino@tirasa.net]
> >>>>>> Sent: Freitag, 14. März 2014 17:54
> >>>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
> >>>>>> Subject: CXF and kerberos authentication
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm an PMC member of Apache Syncope[1].
> >>>>>> We are building a new connector bundle for Connid[2] that needs
> >>>>>> to connect with FreeIpa server.
> >>>>>>
> >>>>>> The connector bundle use JSON-RPC to communicate with the server
> >>>>>> that is protected by Kerberos.
> >>>>>> We followed this guide
> >>>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
> >>>>>> connector not negotiate with Kerberos
> >>>>>>
> >>>>>> WebClient wc =
> >>>>>> WebClient.create("https://olmo.example.com/ipa/json");
> >>>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(c
> >>>>>> lientParam
> >>>>>> eters());
> >>>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
> >>>>>> policy.setAuthorizationType("Negotiate");
> >>>>>> policy.setAuthorization(KEYTAB_CONF);
> >>>>>> KerberosAuthOutInterceptor kbInterceptor = new
> >>>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
> >>>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
> >>>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
> >>>>>> <http://olmo.example.com>");
> >>>>>> kbInterceptor.setCredDelegation(true);
> >>>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
> >>>>>>
> >>>>>> I try a lot of other configuration without success, have you any
> >>>>>> suggestion?
> >>>>>>
> >>>>>> If we run with curl it works.
> >>>>>>
> >>>>>> Regards
> >>>>>> M
> >>>>>>
> >>>>>> [1] http://syncope.apache.org/
> >>>>>> [2] http://tirasa.github.io/ConnId/
> >>>>>>
> >>>>>> --
> >>>>>> Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570
> >>>>>>
> >>>>>> Tirasa S.r.l.
> >>>>>> Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39
> >>>>>> 0859111173 http://www.tirasa.net
> >>>>>>
> >>>>>> Apache Syncope PMC Member
> >>>>>> http://people.apache.org/~mdisabatino/
> >>>>>
> >>>>
> >>>> --
> >>>> Dott. Marco Di Sabatino Di Diodoro
> >>>> Tel. +39 3939065570
> >>>>
> >>>> Tirasa S.r.l.
> >>>> Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39
> >>>> 0859111173 http://www.tirasa.net <http://www.tirasa.net/>
> >>>>
> >>>> Apache Syncope PMC Member
> >>>> http://people.apache.org/~mdisabatino/
> >>>>
> >>>
> >>
> >
> 
> --
> Dott. Marco Di Sabatino Di Diodoro
> Tel. +39 3939065570
> 
> Tirasa S.r.l.
> Viale D'Annunzio 267 - 65127 Pescara
> Tel +39 0859116307 / FAX +39 0859111173
> http://www.tirasa.net
> 
> Apache Syncope PMC Member
> http://people.apache.org/~mdisabatino/

Re: CXF and kerberos authentication

Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.

Hi Sergey,

Il giorno 19/mar/2014, alle ore 10:57, Sergey Beryozkin <sb...@gmail.com> ha scritto:

> Hi Marco
> On 19/03/14 08:44, Marco Di Sabatino Di Diodoro wrote:
>> Hi Sergey
>> 
>> thanks for your support.
>> We asked the FreeIPA community to see if there are some incorrect configurations[1].
>> 
>> I'll let you know when we have news.
>> 
> Sounds good, thanks.
> 
> What concerns me is the fact that using CURL to send Kerberos tokens to FreeIPA works, while using WebClient and Kerberos interceptor does not.
> I suspect that something in the CXF code might need to be tweaked or may be it needs to be reconfigured a bit.
> The logs you sent last time show that CXF manages to obtain a token but it is really a server which does not accept it. So I think CXF does correctly interacts with the Kerberos system, but what appears to be the case is that there is some difference in the way CXF and CURL send tokens.
> 
> Can you please run CURL with -v option and see if you can spot something obvious, compared to the way CXF sends it ?

these days, we are investigating why the call does not work with the java client.
Our goal is to call a jsonrpc api protected from Kerberos. So we trying to call apache httpd with mod_auth_kerb. This is our cxf example [1].

After cxf call, I noticed that httpd log has

[Mon Mar 24 19:03:29.402055 2014] [auth_kerb:debug] [pid 10029] src/mod_auth_kerb.c(1724): [client 192.168.0.105:39499] Client didn't delegate us their credential, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.402084 2014] [auth_kerb:debug] [pid 10029] src/mod_auth_kerb.c(1743): [client 192.168.0.105:39499] GSS-API token of length 186 bytes will be sent back, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.402510 2014] [:info] [pid 10029] nss_hook_Auth
[Mon Mar 24 19:03:29.402577 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of Require valid-user : granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.402676 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.403068 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of Require all granted: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.403172 2014] [authz_core:debug] [pid 10029] mod_authz_core.c(802): [client 192.168.0.105:39499] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:03:29.403908 2014] [:error] [pid 10025] ipa: ERROR: 500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment
[Mon Mar 24 19:03:29.404844 2014] [headers:debug] [pid 10029] mod_headers.c(845): AH01502: headers: ap_headers_output_filter()

Whereas if I done the same call with curl on the httpd log there’s

[Mon Mar 24 19:14:43.329966 2014] [auth_kerb:debug] [pid 10032] src/mod_auth_kerb.c(1724): [client 192.168.0.105:39504] Client delegated us their credential, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:43.329977 2014] [auth_kerb:debug] [pid 10032] src/mod_auth_kerb.c(1743): [client 192.168.0.105:39504] GSS-API token of length 156 bytes will be sent back, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:43.338700 2014] [:info] [pid 10032] nss_hook_Auth
[Mon Mar 24 19:14:43.338721 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of Require valid-user : granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:43.338726 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:43.338878 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of Require all granted: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:43.338886 2014] [authz_core:debug] [pid 10032] mod_authz_core.c(802): [client 192.168.0.105:39504] AH01626: authorization result of <RequireAny>: granted, referer: https://olmo.tirasa.net/ipa
[Mon Mar 24 19:14:44.371738 2014] [:error] [pid 10024] ipa: INFO: admin@TIRASA.NET: user_find(u'', all=u'true'): SUCCESS
[Mon Mar 24 19:14:44.372957 2014] [headers:debug] [pid 10032] mod_headers.c(845): AH01502: headers: ap_headers_output_filter()
[Mon Mar 24 19:14:44.375508 2014] [:info] [pid 10032] Connection to child 4 closed (server olmo.tirasa.net:443, client 192.168.0.105)

Curl with -v option log:

curl -v -H referer:https://olmo.tirasa.net/ipa -H "Content-Type:application/json" -H "Accept:applicaton/json" --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -d  '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' -X POST https://olmo.tirasa.net/ipa/json

* Adding handle: conn: 0xc24ec0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
* About to connect() to olmo.tirasa.net port 443 (#0)
*   Trying 192.168.0.106...
* Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
* 	subject: CN=olmo.tirasa.net,O=TIRASA.NET
* 	start date: mar 13 13:48:58 2014 GMT
* 	expire date: mar 13 13:48:58 2016 GMT
* 	common name: olmo.tirasa.net
* 	issuer: CN=Certificate Authority,O=TIRASA.NET
> POST /ipa/json HTTP/1.1
> User-Agent: curl/7.32.0
> Host: olmo.tirasa.net
> referer:https://olmo.tirasa.net/ipa
> Content-Type:application/json
> Accept:applicaton/json
> Content-Length: 60
> 
* upload completely sent off: 60 out of 60 bytes
< HTTP/1.1 401 Unauthorized
< Date: Tue, 25 Mar 2014 08:17:15 GMT
* Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted
< Server: Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
< WWW-Authenticate: Negotiate
< Last-Modified: Tue, 28 Jan 2014 08:12:54 GMT
< Accept-Ranges: bytes
< Content-Length: 1383
< Content-Type: text/html; charset=UTF-8
< 
* Ignoring the response-body
* Connection #0 to host olmo.tirasa.net left intact
* Issue another request to this URL: 'https://olmo.tirasa.net/ipa/json'
* Found bundle for host olmo.tirasa.net: 0xc258a0
* Re-using existing connection! (#0) with host olmo.tirasa.net
* Connected to olmo.tirasa.net (192.168.0.106) port 443 (#0)
* Adding handle: conn: 0xc24ec0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0xc24ec0) send_pipe: 1, recv_pipe: 0
* Server auth using GSS-Negotiate with user ''
> POST /ipa/json HTTP/1.1
> Authorization: Negotiate YIIE8QYJKoZIhvcSAQICAQBuggTgMIIE3KADAgEFoQMCAQ6iBwMFACAAAACjggFVYYIBUTCCAU2gAwIBBaEMGwpUSVJBU0EuTkVUoiIwIKADAgEBoRkwFxsESFRUUBsPb2xtby50aXJhc2EubmV0o4IBEjCCAQ6gAwIBEqEDAgECooIBAASB/fM6eW0p4pD8wvFfwNLF5R5wq5jjmY4nSCij5Ijom2SFhtxB7GYHIHGmU7/obmkKG2zqW/a7Uw85fLh+lkZJ+z1WjBwNswAOBIQ7+9NaHcOJXGttuyToiqCuUdfm6RndbrZ1e7heIsS9CajEACmOiY5T7hJa2Ld8chN6xHLhbJlqTmcFcRRwHNDA/ehxgGe5xXQg7NZd4LSWbRjsDdS/NlmxY3EPVHZhLn0MCG/sG+b2favQbn9tTfEOU3S5zK47eUNC39e25sN6WkGImGL2d90G0vgnpGFW/DXcqEWH8+wXaVL4fzTR93wkzk56hLhtYvxmjDxOer/6/kXR4z2kggNsMIIDaKADAgESooIDXwSCA1vo49R1NgVJXKb4nhEZAMggkNY+S2SmMgb3m/cc7Hkq6kb+Jz8ClM51SjV5eUYI70dYbp/e8FoZwq5irwfG+s4KKRkhCZX5y8t6cOewU2cp++7J8M8G6GHOw7sm+TOdAQfwsVPWqgHhw69Ih7W48inYazDkyJfr4k9+Vu3IZxjyJBlaF6idV5w8cFK0LuSVrUDtk74MJ+mM08jE0wWONqHcoWD/xYklShavDb0bOvEm7TfvBKYuwsrsGl4ubgphvWcd+DnT/dFjtx583GbiqgSDSbHUEC93C9DIcxnUwqbsMWKDohtsG1dTZp/JfX3yQdoa/lfyn32fIPyP7ucwZWN/hy3JUgizI6WdVR+2z3lqSCG3WIzVAQLYek+SZbQ4gmhOl6SydF7sYlqAjSNoBHSTxB610+pIak/uR2qrqa2VPWlsX8aAKaYrlPSVyckxtTb1G/OFahIZJPA0m/CIYJjFF0E/TnhmkwdPaIHQ5miOVwxDMUL1dBQXO9w1gwCcvbLrt3N43Ogo6DlOGj3Ticst9gZMBXeDPwrnOufB5FZBWtksc9fonyZRyq70c7GOrShwVjqlpG4toZcLRba0kCpggjxmV45o+AedpV9I9fYP8tDV619e1EtDGGKnsSfiRzINqFYA8jlKpSTjVPZNqTPh140bsmqDRQtvSRNfb7ftlLfF+lI7UmCeJB31d6CUQkqr4MV7PO7zAMjji8DSzPgzpjnYAi2Re+kzbJmllEzUQarFMKM9VEmpCO0Q3SKcM64Rw5qRajFwaduQ2oPCe1Mrws++jtxHDvXtm77Rc0NM30uJcriauCj5XYbfMPHnbqHFa+iFB3OtedbU+HAtth2S0IC/47LgoV0GnVLZWU18P0LTtQwiyJ6p/pRpUiMJB8LwjV8eKsZOSnJDFCXN3ulOuC/xEV4/eumQPg9Eq/eYdQH8xoGCUVKiriEfJD9eilYe+fZWJOfwSgHGiddVZqBoAsALjr/snkF8O0oCP2d0YxrBb/xpbLexXEhLw84FtKtthZGsIfEB5JLpeWj/7FDNj3AHWSYq2qg2ajB87p6VTw+eSEspdmPCbn/mzo/IrVr0Iv3RD3tIodcqKWY/sr/VU2YjBKGj/zVbYxOgRf8DohuqOZ4Qglo4dmUi
> User-Agent: curl/7.32.0
> Host: olmo.tirasa.net
> referer:https://olmo.tirasa.net/ipa
> Content-Type:application/json
> Accept:applicaton/json
> Content-Length: 60
> 
* upload completely sent off: 60 out of 60 bytes
< HTTP/1.1 200 Success
< Date: Tue, 25 Mar 2014 08:17:15 GMT
* Server Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5 is not blacklisted
< Server: Apache/2.4.7 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
< WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvc4GoDMzW+ZiPr3J9m2XX/cQl2kVjQBeSNfBy89lI/xnvdDcEArVUOTNJeaKKaGR4W/Tv0op0ZUsVw8M7UHu+tmndta9kYG4WAORN6RHGPL4ww8br/oFtCUAcretWQzkfeOMMHrYjQfvFl3GkjUJs
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: application/json; charset=utf-8
< 
{
    "error": null, 
    "id": 0, 
    "principal": "admin@TIRASA.NET", 
    "result": {
        "count": 1, 
        "messages": [
            {
                "code": 13001, 
                "message": "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.65", 
                "name": "VersionMissing", 
                "type": "warning"
            }
        ], 
        "result": [
            {
                "cn": [
                    "Administrator"
                ], 
                "dn": "uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net", 
                "gecos": [
                    "Administrator"
                ], 
                "gidnumber": [
                    "163600000"
                ], 
                "has_keytab": true, 
                "has_password": true, 
                "homedirectory": [
                    "/home/admin"
                ], 
                "ipauniqueid": [
                    "a524777e-aab5-11e3-bd11-080027e7a744"
                ], 
                "krbextradata": [
                    {
                        "__base64__": "AALItyFTcm9vdC9hZG1pbkBUSVJBU0EuTkVUAA=="
                    }
                ], 
                "krblastpwdchange": [
                    "20140313135104Z"
                ], 
                "krblastsuccessfulauth": [
                    "20140325081717Z"
                ], 
                "krbpasswordexpiration": [
                    "20140611135104Z"
                ], 
                "krbprincipalname": [
                    "admin@TIRASA.NET"
                ], 
                "loginshell": [
                    "/bin/bash"
                ], 
                "memberof_group": [
                    "admins", 
                    "trust admins"
                ], 
                "nsaccountlock": false, 
                "objectclass": [
                    "top", 
                    "person", 
                    "posixaccount", 
                    "krbprincipalaux", 
                    "krbticketpolicyaux", 
                    "inetuser", 
                    "ipaobject", 
                    "ipasshuser", 
                    "ipaSshGroupOfPubKeys"
                ], 
                "sn": [
                    "Administrator"
                ], 
                "uid": [
                    "admin"
                ], 
                "uidnumber": [
                    "163600000"
                ]
            }
        ], 
        "summary": "1 user matched", 
        "truncated": false
    }, 
    "version": "3.3.4"
* Connection #0 to host olmo.tirasa.net left intact

What do you think? Any suggestions?
M

[1] https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/tirasa/kerberosexample/CXFClient.java

> 
> Thanks, Sergey
> 
> 
> 
>> Thanks
>> M
>> 
>> [1] https://www.redhat.com/archives/freeipa-devel/2014-March/msg00296.html
>> 
>> Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin <sb...@gmail.com> ha scritto:
>> 
>>> Hi
>>> How do you configure it with curl ?
>>> In your opinion, what is the difference between the way you set it up in curl and in CXF ?
>>> 
>>> Cheers, Sergey
>>> 
>>> 
>>> 
>>> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
>>>> Hi,
>>>> 
>>>> 
>>>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
>>>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>>>> 
>>>>> Hi Marco,
>>>>> 
>>>>> I would suggest to try simple Kerberos login using JAAS directly (with
>>>>> debug=true), perhaps it helps to spot the problem:
>>>>> 
>>>>> Test code:
>>>>>       URL conf =
>>>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>>>>       System.setProperty("java.security.auth.login.config",
>>>>> conf.toString());
>>>>> 
>>>>>       // Only needed when not using the ticket cache
>>>>>       CallbackHandler callbackHandler = new CallbackHandler() {
>>>>> 
>>>>>           @Override
>>>>>           public void handle(Callback[] callbacks) throws
>>>>> IOException, UnsupportedCallbackException {
>>>>>               for (Callback callback : callbacks) {
>>>>>                   if (callback instanceof NameCallback) {
>>>>>                       ((NameCallback)callback).setName("alice");
>>>>>                   }
>>>>>                   if (callback instanceof PasswordCallback) {
>>>>>                       ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>>>>                   }
>>>>>               }
>>>>> 
>>>>>           }
>>>>>       };
>>>>> 
>>>>>       try {
>>>>>           LoginContext lc = new LoginContext("myContext",
>>>>> callbackHandler);
>>>>>           lc.login();
>>>>>           Subject subject = lc.getSubject();
>>>>>           Set<Principal> principals = subject.getPrincipals();
>>>>>           Set<Object> credentials = subject.getPrivateCredentials();
>>>>>           System.out.println("OK: " + principals);
>>>>>           System.out.println("OK: " + credentials);
>>>>>       } catch (LoginException e) {
>>>>>           e.printStackTrace();
>>>>>       }
>>>>>   }
>>>>> 
>>>>> Jaas.conf:
>>>>> 
>>>>> myContext {
>>>>>   com.sun.security.auth.module.Krb5LoginModule required
>>>>>   debug=true
>>>>>   refreshKrb5Config=true
>>>>>   useKeyTab=true
>>>>>   storeKey=true
>>>>>   keyTab="my.keytab"
>>>>>   principal="my/services.example.com <http://services.example.com>";
>>>>> };
>>>>> 
>>>>> If the code works, you will be able to detect what is different with
>>>>> AbstractSpnegoAuthSupplier.getToken() code used from
>>>>> KerberosAuthOutInterceptor.java.
>>>> 
>>>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>>>> 
>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>> krbtgt/TIRASA.NET@TIRASA.NET <ma...@TIRASA.NET>
>>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
>>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>> 
>>>> If we run with curl:
>>>> 
>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
>>>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET
>>>> <ma...@TIRASA.NET> for krbtgt/TIRASA.NET@TIRASA.NET
>>>> <ma...@TIRASA.NET>
>>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
>>>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
>>>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
>>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>> 
>>>> I have attached the log file of the test connector. As you can see from
>>>> the log, at the beginning we make a login and after a request to the
>>>> service, but returns a 401.
>>>> 
>>>> Thanks
>>>> M
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Andrei.
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>>>>>> Sent: Freitag, 14. März 2014 17:54
>>>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>>>>> Subject: CXF and kerberos authentication
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I'm an PMC member of Apache Syncope[1].
>>>>>> We are building a new connector bundle for Connid[2] that needs to
>>>>>> connect
>>>>>> with FreeIpa server.
>>>>>> 
>>>>>> The connector bundle use JSON-RPC to communicate with the server that is
>>>>>> protected by Kerberos.
>>>>>> We followed this guide
>>>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>>>>> connector not negotiate with Kerberos
>>>>>> 
>>>>>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>>>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>>>>>> eters());
>>>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>>>>> policy.setAuthorizationType("Negotiate");
>>>>>> policy.setAuthorization(KEYTAB_CONF);
>>>>>> KerberosAuthOutInterceptor kbInterceptor = new
>>>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>>>>> <http://olmo.example.com>");
>>>>>> kbInterceptor.setCredDelegation(true);
>>>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>>>> 
>>>>>> I try a lot of other configuration without success, have you any
>>>>>> suggestion?
>>>>>> 
>>>>>> If we run with curl it works.
>>>>>> 
>>>>>> Regards
>>>>>> M
>>>>>> 
>>>>>> [1] http://syncope.apache.org/
>>>>>> [2] http://tirasa.github.io/ConnId/
>>>>>> 
>>>>>> --
>>>>>> Dott. Marco Di Sabatino Di Diodoro
>>>>>> Tel. +39 3939065570
>>>>>> 
>>>>>> Tirasa S.r.l.
>>>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>>>> http://www.tirasa.net
>>>>>> 
>>>>>> Apache Syncope PMC Member
>>>>>> http://people.apache.org/~mdisabatino/
>>>>> 
>>>> 
>>>> --
>>>> Dott. Marco Di Sabatino Di Diodoro
>>>> Tel. +39 3939065570
>>>> 
>>>> Tirasa S.r.l.
>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>> http://www.tirasa.net <http://www.tirasa.net/>
>>>> 
>>>> Apache Syncope PMC Member
>>>> http://people.apache.org/~mdisabatino/
>>>> 
>>> 
>> 
> 

-- 
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/

Re: CXF and kerberos authentication

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi Marco
On 19/03/14 08:44, Marco Di Sabatino Di Diodoro wrote:
> Hi Sergey
>
> thanks for your support.
> We asked the FreeIPA community to see if there are some incorrect configurations[1].
>
> I'll let you know when we have news.
>
Sounds good, thanks.

What concerns me is the fact that using CURL to send Kerberos tokens to 
FreeIPA works, while using WebClient and Kerberos interceptor does not.
I suspect that something in the CXF code might need to be tweaked or may 
be it needs to be reconfigured a bit.
The logs you sent last time show that CXF manages to obtain a token but 
it is really a server which does not accept it. So I think CXF does 
correctly interacts with the Kerberos system, but what appears to be the 
case is that there is some difference in the way CXF and CURL send tokens.

Can you please run CURL with -v option and see if you can spot something 
obvious, compared to the way CXF sends it ?

Thanks, Sergey



> Thanks
> M
>
> [1] https://www.redhat.com/archives/freeipa-devel/2014-March/msg00296.html
>
> Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin <sb...@gmail.com> ha scritto:
>
>> Hi
>> How do you configure it with curl ?
>> In your opinion, what is the difference between the way you set it up in curl and in CXF ?
>>
>> Cheers, Sergey
>>
>>
>>
>> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
>>> Hi,
>>>
>>>
>>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
>>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>>>
>>>> Hi Marco,
>>>>
>>>> I would suggest to try simple Kerberos login using JAAS directly (with
>>>> debug=true), perhaps it helps to spot the problem:
>>>>
>>>> Test code:
>>>>        URL conf =
>>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>>>        System.setProperty("java.security.auth.login.config",
>>>> conf.toString());
>>>>
>>>>        // Only needed when not using the ticket cache
>>>>        CallbackHandler callbackHandler = new CallbackHandler() {
>>>>
>>>>            @Override
>>>>            public void handle(Callback[] callbacks) throws
>>>> IOException, UnsupportedCallbackException {
>>>>                for (Callback callback : callbacks) {
>>>>                    if (callback instanceof NameCallback) {
>>>>                        ((NameCallback)callback).setName("alice");
>>>>                    }
>>>>                    if (callback instanceof PasswordCallback) {
>>>>                        ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>>>                    }
>>>>                }
>>>>
>>>>            }
>>>>        };
>>>>
>>>>        try {
>>>>            LoginContext lc = new LoginContext("myContext",
>>>> callbackHandler);
>>>>            lc.login();
>>>>            Subject subject = lc.getSubject();
>>>>            Set<Principal> principals = subject.getPrincipals();
>>>>            Set<Object> credentials = subject.getPrivateCredentials();
>>>>            System.out.println("OK: " + principals);
>>>>            System.out.println("OK: " + credentials);
>>>>        } catch (LoginException e) {
>>>>            e.printStackTrace();
>>>>        }
>>>>    }
>>>>
>>>> Jaas.conf:
>>>>
>>>> myContext {
>>>>    com.sun.security.auth.module.Krb5LoginModule required
>>>>    debug=true
>>>>    refreshKrb5Config=true
>>>>    useKeyTab=true
>>>>    storeKey=true
>>>>    keyTab="my.keytab"
>>>>    principal="my/services.example.com <http://services.example.com>";
>>>> };
>>>>
>>>> If the code works, you will be able to detect what is different with
>>>> AbstractSpnegoAuthSupplier.getToken() code used from
>>>> KerberosAuthOutInterceptor.java.
>>>
>>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>>>
>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>> krbtgt/TIRASA.NET@TIRASA.NET <ma...@TIRASA.NET>
>>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
>>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>
>>> If we run with curl:
>>>
>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
>>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET
>>> <ma...@TIRASA.NET> for krbtgt/TIRASA.NET@TIRASA.NET
>>> <ma...@TIRASA.NET>
>>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
>>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
>>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
>>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>>>
>>> I have attached the log file of the test connector. As you can see from
>>> the log, at the beginning we make a login and after a request to the
>>> service, but returns a 401.
>>>
>>> Thanks
>>> M
>>>
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Andrei.
>>>>
>>>>> -----Original Message-----
>>>>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>>>>> Sent: Freitag, 14. März 2014 17:54
>>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>>>> Subject: CXF and kerberos authentication
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm an PMC member of Apache Syncope[1].
>>>>> We are building a new connector bundle for Connid[2] that needs to
>>>>> connect
>>>>> with FreeIpa server.
>>>>>
>>>>> The connector bundle use JSON-RPC to communicate with the server that is
>>>>> protected by Kerberos.
>>>>> We followed this guide
>>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>>>> connector not negotiate with Kerberos
>>>>>
>>>>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>>>>> eters());
>>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>>>> policy.setAuthorizationType("Negotiate");
>>>>> policy.setAuthorization(KEYTAB_CONF);
>>>>> KerberosAuthOutInterceptor kbInterceptor = new
>>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>>>> <http://olmo.example.com>");
>>>>> kbInterceptor.setCredDelegation(true);
>>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>>>
>>>>> I try a lot of other configuration without success, have you any
>>>>> suggestion?
>>>>>
>>>>> If we run with curl it works.
>>>>>
>>>>> Regards
>>>>> M
>>>>>
>>>>> [1] http://syncope.apache.org/
>>>>> [2] http://tirasa.github.io/ConnId/
>>>>>
>>>>> --
>>>>> Dott. Marco Di Sabatino Di Diodoro
>>>>> Tel. +39 3939065570
>>>>>
>>>>> Tirasa S.r.l.
>>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>>> http://www.tirasa.net
>>>>>
>>>>> Apache Syncope PMC Member
>>>>> http://people.apache.org/~mdisabatino/
>>>>
>>>
>>> --
>>> Dott. Marco Di Sabatino Di Diodoro
>>> Tel. +39 3939065570
>>>
>>> Tirasa S.r.l.
>>> Viale D'Annunzio 267 - 65127 Pescara
>>> Tel +39 0859116307 / FAX +39 0859111173
>>> http://www.tirasa.net <http://www.tirasa.net/>
>>>
>>> Apache Syncope PMC Member
>>> http://people.apache.org/~mdisabatino/
>>>
>>
>

Re: CXF and kerberos authentication

Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.

Hi Sergey

thanks for your support.
We asked the FreeIPA community to see if there are some incorrect configurations[1]. 

I'll let you know when we have news.

Thanks
M

[1] https://www.redhat.com/archives/freeipa-devel/2014-March/msg00296.html

Il giorno 17/mar/2014, alle ore 19:10, Sergey Beryozkin <sb...@gmail.com> ha scritto:

> Hi
> How do you configure it with curl ?
> In your opinion, what is the difference between the way you set it up in curl and in CXF ?
> 
> Cheers, Sergey
> 
> 
> 
> On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
>> Hi,
>> 
>> 
>> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
>> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>> 
>>> Hi Marco,
>>> 
>>> I would suggest to try simple Kerberos login using JAAS directly (with
>>> debug=true), perhaps it helps to spot the problem:
>>> 
>>> Test code:
>>>       URL conf =
>>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>>       System.setProperty("java.security.auth.login.config",
>>> conf.toString());
>>> 
>>>       // Only needed when not using the ticket cache
>>>       CallbackHandler callbackHandler = new CallbackHandler() {
>>> 
>>>           @Override
>>>           public void handle(Callback[] callbacks) throws
>>> IOException, UnsupportedCallbackException {
>>>               for (Callback callback : callbacks) {
>>>                   if (callback instanceof NameCallback) {
>>>                       ((NameCallback)callback).setName("alice");
>>>                   }
>>>                   if (callback instanceof PasswordCallback) {
>>>                       ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>>                   }
>>>               }
>>> 
>>>           }
>>>       };
>>> 
>>>       try {
>>>           LoginContext lc = new LoginContext("myContext",
>>> callbackHandler);
>>>           lc.login();
>>>           Subject subject = lc.getSubject();
>>>           Set<Principal> principals = subject.getPrincipals();
>>>           Set<Object> credentials = subject.getPrivateCredentials();
>>>           System.out.println("OK: " + principals);
>>>           System.out.println("OK: " + credentials);
>>>       } catch (LoginException e) {
>>>           e.printStackTrace();
>>>       }
>>>   }
>>> 
>>> Jaas.conf:
>>> 
>>> myContext {
>>>   com.sun.security.auth.module.Krb5LoginModule required
>>>   debug=true
>>>   refreshKrb5Config=true
>>>   useKeyTab=true
>>>   storeKey=true
>>>   keyTab="my.keytab"
>>>   principal="my/services.example.com <http://services.example.com>";
>>> };
>>> 
>>> If the code works, you will be able to detect what is different with
>>> AbstractSpnegoAuthSupplier.getToken() code used from
>>> KerberosAuthOutInterceptor.java.
>> 
>> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>> 
>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>> krbtgt/TIRASA.NET@TIRASA.NET <ma...@TIRASA.NET>
>> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
>> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
>> admin@TIRASA.NET <ma...@TIRASA.NET> for
>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>> 
>> If we run with curl:
>> 
>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
>> authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET
>> <ma...@TIRASA.NET> for krbtgt/TIRASA.NET@TIRASA.NET
>> <ma...@TIRASA.NET>
>> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
>> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
>> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
>> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
>> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>> 
>> I have attached the log file of the test connector. As you can see from
>> the log, at the beginning we make a login and after a request to the
>> service, but returns a 401.
>> 
>> Thanks
>> M
>> 
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Andrei.
>>> 
>>>> -----Original Message-----
>>>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>>>> Sent: Freitag, 14. März 2014 17:54
>>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>>> Subject: CXF and kerberos authentication
>>>> 
>>>> Hi,
>>>> 
>>>> I'm an PMC member of Apache Syncope[1].
>>>> We are building a new connector bundle for Connid[2] that needs to
>>>> connect
>>>> with FreeIpa server.
>>>> 
>>>> The connector bundle use JSON-RPC to communicate with the server that is
>>>> protected by Kerberos.
>>>> We followed this guide
>>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>>> connector not negotiate with Kerberos
>>>> 
>>>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>>>> eters());
>>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>>> policy.setAuthorizationType("Negotiate");
>>>> policy.setAuthorization(KEYTAB_CONF);
>>>> KerberosAuthOutInterceptor kbInterceptor = new
>>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>>> <http://olmo.example.com>");
>>>> kbInterceptor.setCredDelegation(true);
>>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>> 
>>>> I try a lot of other configuration without success, have you any
>>>> suggestion?
>>>> 
>>>> If we run with curl it works.
>>>> 
>>>> Regards
>>>> M
>>>> 
>>>> [1] http://syncope.apache.org/
>>>> [2] http://tirasa.github.io/ConnId/
>>>> 
>>>> --
>>>> Dott. Marco Di Sabatino Di Diodoro
>>>> Tel. +39 3939065570
>>>> 
>>>> Tirasa S.r.l.
>>>> Viale D'Annunzio 267 - 65127 Pescara
>>>> Tel +39 0859116307 / FAX +39 0859111173
>>>> http://www.tirasa.net
>>>> 
>>>> Apache Syncope PMC Member
>>>> http://people.apache.org/~mdisabatino/
>>> 
>> 
>> --
>> Dott. Marco Di Sabatino Di Diodoro
>> Tel. +39 3939065570
>> 
>> Tirasa S.r.l.
>> Viale D'Annunzio 267 - 65127 Pescara
>> Tel +39 0859116307 / FAX +39 0859111173
>> http://www.tirasa.net <http://www.tirasa.net/>
>> 
>> Apache Syncope PMC Member
>> http://people.apache.org/~mdisabatino/
>> 
> 

-- 
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/

Re: CXF and kerberos authentication

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi
How do you configure it with curl ?
In your opinion, what is the difference between the way you set it up in 
curl and in CXF ?

Cheers, Sergey



On 17/03/14 15:53, Marco Di Sabatino Di Diodoro wrote:
> Hi,
>
>
> Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin
> <ashakirin@talend.com <ma...@talend.com>> ha scritto:
>
>> Hi Marco,
>>
>> I would suggest to try simple Kerberos login using JAAS directly (with
>> debug=true), perhaps it helps to spot the problem:
>>
>> Test code:
>>        URL conf =
>> JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>>        System.setProperty("java.security.auth.login.config",
>> conf.toString());
>>
>>        // Only needed when not using the ticket cache
>>        CallbackHandler callbackHandler = new CallbackHandler() {
>>
>>            @Override
>>            public void handle(Callback[] callbacks) throws
>> IOException, UnsupportedCallbackException {
>>                for (Callback callback : callbacks) {
>>                    if (callback instanceof NameCallback) {
>>                        ((NameCallback)callback).setName("alice");
>>                    }
>>                    if (callback instanceof PasswordCallback) {
>>                        ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>>                    }
>>                }
>>
>>            }
>>        };
>>
>>        try {
>>            LoginContext lc = new LoginContext("myContext",
>> callbackHandler);
>>            lc.login();
>>            Subject subject = lc.getSubject();
>>            Set<Principal> principals = subject.getPrincipals();
>>            Set<Object> credentials = subject.getPrivateCredentials();
>>            System.out.println("OK: " + principals);
>>            System.out.println("OK: " + credentials);
>>        } catch (LoginException e) {
>>            e.printStackTrace();
>>        }
>>    }
>>
>> Jaas.conf:
>>
>> myContext {
>>    com.sun.security.auth.module.Krb5LoginModule required
>>    debug=true
>>    refreshKrb5Config=true
>>    useKeyTab=true
>>    storeKey=true
>>    keyTab="my.keytab"
>>    principal="my/services.example.com <http://services.example.com>";
>> };
>>
>> If the code works, you will be able to detect what is different with
>> AbstractSpnegoAuthSupplier.getToken() code used from
>> KerberosAuthOutInterceptor.java.
>
> this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:
>
> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
> krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176:
> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
> admin@TIRASA.NET <ma...@TIRASA.NET> for
> krbtgt/TIRASA.NET@TIRASA.NET <ma...@TIRASA.NET>
> mar 17 16:03:10 olmo.tirasa.net <http://olmo.tirasa.net>
> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176:
> ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18},
> admin@TIRASA.NET <ma...@TIRASA.NET> for
> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>
> If we run with curl:
>
> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
> krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE:
> authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET
> <ma...@TIRASA.NET> for krbtgt/TIRASA.NET@TIRASA.NET
> <ma...@TIRASA.NET>
> mar 17 16:14:06 olmo.tirasa.net <http://olmo.tirasa.net>
> krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26})
> 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18
> ses=18}, admin@TIRASA.NET <ma...@TIRASA.NET> for
> ldap/olmo.tirasa.net@TIRASA.NET <ma...@TIRASA.NET>
>
> I have attached the log file of the test connector. As you can see from
> the log, at the beginning we make a login and after a request to the
> service, but returns a 401.
>
> Thanks
> M
>
>
>
>
>>
>> Regards,
>> Andrei.
>>
>>> -----Original Message-----
>>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>>> Sent: Freitag, 14. März 2014 17:54
>>> To: users@cxf.apache.org <ma...@cxf.apache.org>
>>> Subject: CXF and kerberos authentication
>>>
>>> Hi,
>>>
>>> I'm an PMC member of Apache Syncope[1].
>>> We are building a new connector bundle for Connid[2] that needs to
>>> connect
>>> with FreeIpa server.
>>>
>>> The connector bundle use JSON-RPC to communicate with the server that is
>>> protected by Kerberos.
>>> We followed this guide
>>> (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>>> connector not negotiate with Kerberos
>>>
>>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>>> eters());
>>> AuthorizationPolicy policy = new AuthorizationPolicy();
>>> policy.setAuthorizationType("Negotiate");
>>> policy.setAuthorization(KEYTAB_CONF);
>>> KerberosAuthOutInterceptor kbInterceptor = new
>>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>>> kbInterceptor.setRealm("EXAMPLE.COM <http://EXAMPLE.COM>");
>>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com
>>> <http://olmo.example.com>");
>>> kbInterceptor.setCredDelegation(true);
>>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>>>
>>> I try a lot of other configuration without success, have you any
>>> suggestion?
>>>
>>> If we run with curl it works.
>>>
>>> Regards
>>> M
>>>
>>> [1] http://syncope.apache.org/
>>> [2] http://tirasa.github.io/ConnId/
>>>
>>> --
>>> Dott. Marco Di Sabatino Di Diodoro
>>> Tel. +39 3939065570
>>>
>>> Tirasa S.r.l.
>>> Viale D'Annunzio 267 - 65127 Pescara
>>> Tel +39 0859116307 / FAX +39 0859111173
>>> http://www.tirasa.net
>>>
>>> Apache Syncope PMC Member
>>> http://people.apache.org/~mdisabatino/
>>
>
> --
> Dott. Marco Di Sabatino Di Diodoro
> Tel. +39 3939065570
>
> Tirasa S.r.l.
> Viale D'Annunzio 267 - 65127 Pescara
> Tel +39 0859116307 / FAX +39 0859111173
> http://www.tirasa.net <http://www.tirasa.net/>
>
> Apache Syncope PMC Member
> http://people.apache.org/~mdisabatino/
>

Re: CXF and kerberos authentication

Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.

Hi,


Il giorno 15/mar/2014, alle ore 13:38, Andrei Shakirin <as...@talend.com> ha scritto:

> Hi Marco,
> 
> I would suggest to try simple Kerberos login using JAAS directly (with debug=true), perhaps it helps to spot the problem:
> 
> Test code:
>        URL conf = JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
>        System.setProperty("java.security.auth.login.config", conf.toString());
> 
>        // Only needed when not using the ticket cache
>        CallbackHandler callbackHandler = new CallbackHandler() {
> 
>            @Override
>            public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
>                for (Callback callback : callbacks) {                
>                    if (callback instanceof NameCallback) {
>                        ((NameCallback)callback).setName("alice");
>                    }
>                    if (callback instanceof PasswordCallback) {
>                        ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
>                    }
>                }
> 
>            }
>        };
> 
>        try {
>            LoginContext lc = new LoginContext("myContext", callbackHandler);
>            lc.login();
>            Subject subject = lc.getSubject();
>            Set<Principal> principals = subject.getPrincipals();
>            Set<Object> credentials = subject.getPrivateCredentials();
>            System.out.println("OK: " + principals);
>            System.out.println("OK: " + credentials);
>        } catch (LoginException e) {
>            e.printStackTrace();
>        } 
>    }
> 
> Jaas.conf:
> 
> myContext { 
>    com.sun.security.auth.module.Krb5LoginModule required
>    debug=true
>    refreshKrb5Config=true
>    useKeyTab=true
>    storeKey=true
>    keyTab="my.keytab"
>    principal="my/services.example.com";
> };
> 
> If the code works, you will be able to detect what is different with AbstractSpnegoAuthSupplier.getToken() code used from KerberosAuthOutInterceptor.java.

this are krb5kdc.log when needs to connect with cxf to FreeIpa Server:

mar 17 16:03:10 olmo.tirasa.net krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.176: ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET for krbtgt/TIRASA.NET@TIRASA.NET
mar 17 16:03:10 olmo.tirasa.net krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.176: ISSUE: authtime 1395068590, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET for ldap/olmo.tirasa.net@TIRASA.NET

If we run with curl:

mar 17 16:14:06 olmo.tirasa.net krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET for krbtgt/TIRASA.NET@TIRASA.NET
mar 17 16:14:06 olmo.tirasa.net krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395069156, etypes {rep=18 tkt=18 ses=18}, admin@TIRASA.NET for ldap/olmo.tirasa.net@TIRASA.NET

I have attached the log file of the test connector. As you can see from the log, at the beginning we make a login and after a request to the service, but returns a 401.

Thanks
M


> 
> Regards,
> Andrei.
> 
>> -----Original Message-----
>> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
>> Sent: Freitag, 14. März 2014 17:54
>> To: users@cxf.apache.org
>> Subject: CXF and kerberos authentication
>> 
>> Hi,
>> 
>> I'm an PMC member of Apache Syncope[1].
>> We are building a new connector bundle for Connid[2] that needs to connect
>> with FreeIpa server.
>> 
>> The connector bundle use JSON-RPC to communicate with the server that is
>> protected by Kerberos.
>> We followed this guide (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
>> connector not negotiate with Kerberos
>> 
>> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
>> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
>> eters());
>> AuthorizationPolicy policy = new AuthorizationPolicy();
>> policy.setAuthorizationType("Negotiate");
>> policy.setAuthorization(KEYTAB_CONF);
>> KerberosAuthOutInterceptor kbInterceptor = new
>> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
>> kbInterceptor.setRealm("EXAMPLE.COM");
>> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com");
>> kbInterceptor.setCredDelegation(true);
>> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
>> 
>> I try a lot of other configuration without success, have you any suggestion?
>> 
>> If we run with curl it works.
>> 
>> Regards
>> M
>> 
>> [1] http://syncope.apache.org/
>> [2] http://tirasa.github.io/ConnId/
>> 
>> --
>> Dott. Marco Di Sabatino Di Diodoro
>> Tel. +39 3939065570
>> 
>> Tirasa S.r.l.
>> Viale D'Annunzio 267 - 65127 Pescara
>> Tel +39 0859116307 / FAX +39 0859111173
>> http://www.tirasa.net
>> 
>> Apache Syncope PMC Member
>> http://people.apache.org/~mdisabatino/
> 

-- 
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/

RE: CXF and kerberos authentication

Posted by Andrei Shakirin <as...@talend.com>.

Hi Marco,

I would suggest to try simple Kerberos login using JAAS directly (with debug=true), perhaps it helps to spot the problem:

Test code:
        URL conf = JaasLoginTest.class.getClassLoader().getResource("jaas.conf");
        System.setProperty("java.security.auth.login.config", conf.toString());
        
        // Only needed when not using the ticket cache
        CallbackHandler callbackHandler = new CallbackHandler() {
            
            @Override
            public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
                for (Callback callback : callbacks) {                
                    if (callback instanceof NameCallback) {
                        ((NameCallback)callback).setName("alice");
                    }
                    if (callback instanceof PasswordCallback) {
                        ((PasswordCallback)callback).setPassword("clarinet".toCharArray());
                    }
                }
                
            }
        };

        try {
            LoginContext lc = new LoginContext("myContext", callbackHandler);
            lc.login();
            Subject subject = lc.getSubject();
            Set<Principal> principals = subject.getPrincipals();
            Set<Object> credentials = subject.getPrivateCredentials();
            System.out.println("OK: " + principals);
            System.out.println("OK: " + credentials);
        } catch (LoginException e) {
            e.printStackTrace();
        } 
    }

Jaas.conf:

myContext { 
    com.sun.security.auth.module.Krb5LoginModule required
    debug=true
    refreshKrb5Config=true
    useKeyTab=true
    storeKey=true
    keyTab="my.keytab"
    principal="my/services.example.com";
};

If the code works, you will be able to detect what is different with AbstractSpnegoAuthSupplier.getToken() code used from KerberosAuthOutInterceptor.java.

Regards,
Andrei.

> -----Original Message-----
> From: Marco Di Sabatino Di Diodoro [mailto:marco.disabatino@tirasa.net]
> Sent: Freitag, 14. März 2014 17:54
> To: users@cxf.apache.org
> Subject: CXF and kerberos authentication
> 
> Hi,
> 
> I'm an PMC member of Apache Syncope[1].
> We are building a new connector bundle for Connid[2] that needs to connect
> with FreeIpa server.
> 
> The connector bundle use JSON-RPC to communicate with the server that is
> protected by Kerberos.
> We followed this guide (http://cxf.apache.org/docs/jaxrs-kerberos.html) but the
> connector not negotiate with Kerberos
> 
> WebClient wc = WebClient.create("https://olmo.example.com/ipa/json");
> WebClient.getConfig(wc).getHttpConduit().setTlsClientParameters(clientParam
> eters());
> AuthorizationPolicy policy = new AuthorizationPolicy();
> policy.setAuthorizationType("Negotiate");
> policy.setAuthorization(KEYTAB_CONF);
> KerberosAuthOutInterceptor kbInterceptor = new
> KerberosAuthOutInterceptor(); kbInterceptor.setPolicy(policy);
> kbInterceptor.setRealm("EXAMPLE.COM");
> kbInterceptor.setServicePrincipalName("ldap/olmo.example.com");
> kbInterceptor.setCredDelegation(true);
> WebClient.getConfig(wc).getOutInterceptors().add(kbInterceptor);
> 
> I try a lot of other configuration without success, have you any suggestion?
> 
> If we run with curl it works.
> 
> Regards
> M
> 
> [1] http://syncope.apache.org/
> [2] http://tirasa.github.io/ConnId/
> 
> --
> Dott. Marco Di Sabatino Di Diodoro
> Tel. +39 3939065570
> 
> Tirasa S.r.l.
> Viale D'Annunzio 267 - 65127 Pescara
> Tel +39 0859116307 / FAX +39 0859111173
> http://www.tirasa.net
> 
> Apache Syncope PMC Member
> http://people.apache.org/~mdisabatino/