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 <sberyoz...@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:
ad...@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": "ad...@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": [
"ad...@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 <sberyoz...@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
<ashaki...@talend.com <mailto:ashaki...@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},
ad...@tirasa.net <mailto:ad...@tirasa.net> for
krbtgt/tirasa....@tirasa.net <mailto:krbtgt/tirasa....@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},
ad...@tirasa.net <mailto:ad...@tirasa.net> for
ldap/olmo.tirasa....@tirasa.net <mailto:ldap/olmo.tirasa....@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}, ad...@tirasa.net
<mailto:ad...@tirasa.net> for krbtgt/tirasa....@tirasa.net
<mailto:krbtgt/tirasa....@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}, ad...@tirasa.net <mailto:ad...@tirasa.net> for
ldap/olmo.tirasa....@tirasa.net <mailto:ldap/olmo.tirasa....@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.disabat...@tirasa.net]
Sent: Freitag, 14. März 2014 17:54
To: users@cxf.apache.org <mailto: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 <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/
