Below is a simple configuration for the jaxws-maven-plugin. The trick is to get the jaxws plugin to generate the java sources at the right time and in the right place so that the maven-compiler-plugin with its default settings can find the files when it needs them.
Configuring the jaxws plugging so that it executes the wsimport goal at the right time is done by the phase entry.
Making sure that the plugin puts the files in the right location is accomplished by the sourceDestDir element.
The only the that needs to be modified is the wsdlUrl entry and the finalName elements.
..
<build>
<finalName>web-app</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals><goal>wsimport</goal></goals>
<configuration>
<wsdlUrls>
<wsdlUrl>http://hostname/context/SDMXQuery?wsdl</wsdlUrl>
</wsdlUrls>
<sourceDestDir>${project.build.directory}/generated-sources</sourceDestDir>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
..
I'm using the Krb5LoginModule in a java application to test a web application that I'm trying to kerberized. Before testing, I authorized myself again the AS (in this case ApacheDS) by calling kinit as follows:
kinit.exe wmmnpr@EXAMPLE.COM
Password for wmmnpr@EXAMPLE.COM:
New ticket is stored in cache file C:\Users\wnpr\krb5cc_wnpr
Then I ran my test and as one can see from the log output of Krb5LoginModule below, the login module finds my credential's cache and retrieves a TGT from it.
Acquire TGT from Cache
>>>KinitOptions cache name is C:\Users\wnpr\krb5cc_wnpr
>>>DEBUG <CCacheInputStream> client principal is wmmnpr@EXAMPLE.COM
>>>DEBUG <CCacheInputStream> server principal is krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>>DEBUG <CCacheInputStream> key type: 17
>>>DEBUG <CCacheInputStream> auth time: Tue Jun 03 10:03:36 CEST 2014
>>>DEBUG <CCacheInputStream> start time: null
>>>DEBUG <CCacheInputStream> end time: Wed Jun 04 10:03:36 CEST 2014
>>>DEBUG <CCacheInputStream> renew_till time: null
>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH;
Host address is /172.28.10.201
Host address is /fe80:0:0:0:e11d:3dff:8612:e63b
>>> KrbCreds found the default ticket granting ticket in credential cache.
Config name: C:\Users\wnpr\krb5.conf
>>> Obtained TGT from LSA: Credentials:
client=wmmnpr@EXAMPLE.COM
server=krbtgt/EXAMPLE.COM@EXAMPLE.COM
authTime=20140603080336Z
endTime=20140604080336Z
renewTill=null
flags: INITIAL;PRE-AUTHENT
EType (int): 17
Principal is wmmnpr@EXAMPLE.COM
Commit Succeeded
However, before trying to access the web application, the login module tries to go to the KDC (again ApacheDS) to get a ticket; however, before it gets there a KrbException is thrown (see below).
Found ticket for wmmnpr@EXAMPLE.COM to go to krbtgt/EXAMPLE.COM@EXAMPLE.COM expiring on Wed Jun 04 10:03:36 CEST 2014
Entered Krb5Context.initSecContext with state=STATE_NEW
Service ticket not found in the subject
>>> Credentials acquireServiceCreds: same realm
KrbException: Invalid option setting in ticket request. (101)
at sun.security.krb5.KrbTgsReq.<init>(KrbTgsReq.java:98)
at sun.security.krb5.KrbTgsReq.<init>(KrbTgsReq.java:62)
After looking at the sun.security.krb5.KrbTgsReq code at line 98 it occurred to me that it was the "forwardable" option that was causing problems. I then ran kinit as follows, with -f:
>kinit.exe -f wmmnpr@EXAMPLE.COM
Password for wmmnpr@EXAMPLE.COM:
New ticket is stored in cache file C:\Users\wnpr\krb5cc_wnpr
And then check it with klist.
klist" -f -e -c c:\Users\wnpr\krb5cc_wnpr
Credentials cache: c:\Users\wnpr\krb5cc_wnpr
Default principal: wmmnpr@EXAMPLE.COM, 1 entry found.
[1] Service Principal: krbtgt/EXAMPLE.COM@EXAMPLE.COM
Valid starting: Jun 03, 2014 11:18
Expires: Jun 04, 2014 11:18
Encryption type: AES128 CTS mode with HMAC SHA1-96
Flags: FORWARDABLE;INITIAL;PRE-AUTHENT
While trying to kerberize a web application, I ran into the following error on the KDC server, which happened to be ApacheDS.
IllegalBlockSizeException: Input length not multiple of 8 bytes.
Eventually, I was able to isolate the problem in the krb5.conf file of the client. When the default_tgs_enctype and the default_tkt_enctype were not explicitly specified, as shown below, the problem went away and the KDC could successfully generate either TGS-REP or AS-REP responses.
#/------------------------------- start of krb5.conf --------------------------/
[libdefaults]
default_realm = EXAMPLE.COM
# default_tgs_enctypes = des-cbc-md5,des3-cbc-sha1-kd
# default_tkt_enctypes = des-cbc-md5,des3-cbc-sha1-kd
kdc_timeout = 5000
dns_lookup_realm = false
dns_lookup_kdc = false
allow_weak_crypto = yes
forwardable = true
ap_req_checksum_type = 12
[realms]
EXAMPLE.COM = {
kdc = 127.0.0.1:60088
}
[login]
krb4_convert = true
krb4_get_tickets = false
#/------------------------------- end of krb5.conf ----------------------------/
ApacheDS log output after a TGS_REQ:
INFO | jvm 1 | 2014/06/01 17:50:49 | [17:50:49] DEBUG [org.apache.directory.server.KERBEROS_LOG] - /127.0.0.1:54210 SENT:
INFO | jvm 1 | 2014/06/01 17:50:49 | >-------------------------------------------------------------------------------
INFO | jvm 1 | 2014/06/01 17:50:49 | KdcRep : TGS-REP
INFO | jvm 1 | 2014/06/01 17:50:49 | pvno : 5
INFO | jvm 1 | 2014/06/01 17:50:49 | msg-type : TGS_REP
INFO | jvm 1 | 2014/06/01 17:50:49 | crealm : EXAMPLE.COM
INFO | jvm 1 | 2014/06/01 17:50:49 | cname : { name-type: KRB_NT_PRINCIPAL, name-string : <'wmmnpr'> }
INFO | jvm 1 | 2014/06/01 17:50:49 | Ticket :
INFO | jvm 1 | 2014/06/01 17:50:49 | tkt-vno : 5
INFO | jvm 1 | 2014/06/01 17:50:49 | realm : EXAMPLE.COM
INFO | jvm 1 | 2014/06/01 17:50:49 | sname : { name-type: KRB_NT_UNKNOWN, name-string : <'HTTP', 'example.com'> }
INFO | jvm 1 | 2014/06/01 17:50:49 | enc-part : EncryptedData : {
INFO | jvm 1 | 2014/06/01 17:50:49 | etype: aes128-cts-hmac-sha1-96 (17)
INFO | jvm 1 | 2014/06/01 17:50:49 | cipher: 0x0D 0x56 0xC4 0x0C 0x01 0x9E 0x62 0x6E 0x28 0x45 ....
INFO | jvm 1 | 2014/06/01 17:50:49 | }
INFO | jvm 1 | 2014/06/01 17:50:49 |
INFO | jvm 1 | 2014/06/01 17:50:49 | EncryptedData : {
INFO | jvm 1 | 2014/06/01 17:50:49 | etype: aes128-cts-hmac-sha1-96 (17)
INFO | jvm 1 | 2014/06/01 17:50:49 | cipher: 0x94 0x75 0xE9 0x4C 0xDA 0x6D 0x79 0xDC 0x49 0x0E ...
INFO | jvm 1 | 2014/06/01 17:50:49 | }
INFO | jvm 1 | 2014/06/01 17:50:49 |
INFO | jvm 1 | 2014/06/01 17:50:49 | -------------------------------------------------------------------------------<
INFO | jvm 1 | 2014/06/01 17:50:49 |
