date:20170508

RE: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails

2017-05-08 Thread Zheng, Kai

I’m not sure about this and wonder it may not work. But I have no idea for now 
how to extract the TGT correctly.
encKdcRepPart = new EncAsRepPart();
encKdcRepPart.setAuthTime(cred.getAuthTime());
encKdcRepPart.setCaddr(cred.getClientAddresses());
encKdcRepPart.setEndTime(cred.getEndTime());
encKdcRepPart.setFlags(cred.getTicketFlags());
encKdcRepPart.setKey(cred.getKey());
encKdcRepPart.setRenewTill(cred.getRenewTill());
encKdcRepPart.setSname(cred.getServerName());
encKdcRepPart.setSrealm(cred.getServerName().getRealm());
encKdcRepPart.setStartTime(cred.getStartTime());

From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Tuesday, May 09, 2017 1:34 PM
To: kerby@directory.apache.org
Subject: Re: Using Kerby kerb-client as an alternative for GSS-API Sgt 
Request fails


Hi all

I can now retrieve the Tgt from the creds-cache, and request a Sgt. However I 
am now bouncing between 2 errors. "ERR BAD OPTION" and "ERR GENERIC".

If I create the Tgt with the clientPrincipal, the request is rejected by the 
KDC with "ERR BAD OPTION".

Examining the request with Wireshark shows a cname element in the req-body. 
This is not present in successful requests via GSS-API.

cname
name-type: kRB5-NT-PRINCIPAL (1)
cname-string: 1 item
CNameString: lamb

The KDC log shows "TGT NOT PROXIABLE:" for the failed request.


On the other hand, if I fill the clientPrincipal on the Tgt with null the 
request is rejected by the KDC with "ERR GENERIC".

The cname element is no longer present in the request body (which now looks 
identical that made by GSS-API).

The KDC logs show "ASN.1 structure is missing a required field". I suspect this 
refers to the encrypted "app-req/authenticator/cname",
which debugging shows is now null!


private TgtTicket retrieveCachedTicket(File ccacheFile) throws KrbException {

Ticket ticket = null;
PrincipalName clientPrincipal = null;
EncAsRepPart encKdcRepPart = null;

if (ccacheFile.exists() && ccacheFile.canRead()) {
CredentialCache cCache = new CredentialCache();
try {
cCache.load(ccacheFile);

List credentials = cCache.getCredentials();

for (Credential cred : credentials) {
//we only want a tgt
if (cred.getServerName().toString().startsWith("krbtgt")) {
ticket = cred.getTicket();
clientPrincipal = cred.getClientName();

encKdcRepPart = new EncAsRepPart();
encKdcRepPart.setAuthTime(cred.getAuthTime());
encKdcRepPart.setCaddr(cred.getClientAddresses());
encKdcRepPart.setEndTime(cred.getEndTime());
encKdcRepPart.setFlags(cred.getTicketFlags());
encKdcRepPart.setKey(cred.getKey());
encKdcRepPart.setRenewTill(cred.getRenewTill());
encKdcRepPart.setSname(cred.getServerName());
encKdcRepPart.setSrealm(cred.getServerName().getRealm());
encKdcRepPart.setStartTime(cred.getStartTime());
}
}

} catch (IOException e) {
throw new KrbException("Failed to load credentials", e);
}
} else {
throw new IllegalArgumentException("Invalid ccache file, "
+ "does not exist, or is not readable: " + ccacheFile.getAbsolutePath());
}
return new TgtTicket(ticket, encKdcRepPart, clientPrincipal);
}


private void getKerbyServiceTicket() {
try {
File confFileDir = new File("/home/lamb/OTMS/kerberosTesting/");
KrbClient krbClient = new KrbClient(confFileDir);

krbClient.setKdcHost("kdc.acme.com");
krbClient.setAllowUdp(true);
krbClient.setAllowTcp(true);
krbClient.setKdcUdpPort(88);
krbClient.setKdcTcpPort(88);
krbClient.init();

File credsCache = new File("/tmp/krb5cc_9337");

TgtTicket tgtTicket = retrieveCachedTicket(credsCache);

KOptions requestOptions = new KOptions();
requestOptions.add(KrbKdcOption.PROXIABLE, true);
requestOptions.add(KrbKdcOption.FORWARDABLE);
requestOptions.add(KrbKdcOption.CANONICALIZE, true);
requestOptions.add(KrbKdcOption.RENEWABLE_OK, false);
requestOptions.add(KrbOption.USE_TGT, tgtTicket);

requestOptions.add(KrbOption.SERVER_PRINCIPAL, 
"HTTP/app-srv.acme@acme.com");

SgtTicket sgtTicket = krbClient.requestSgt(requestOptions);


} catch (KrbException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

}

Rejected Request "BAD OPTION":

tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value: 6e82023b30820237a003020105a10302010ea2070305...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 
0...  = reserved: False
.0..  = use-session-key: False
..0.  = mutual-required: False
ticket
tkt-vno: 5
realm: ACME.COM
sname
name-type: kRB5-NT-PRINCIPAL (1)
sname-string: 2 items
SNameString: krbtgt
SNameString: ACME.COM
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 1
cipher: c2da50b960fdfdc44e098ee243f0aa698cfad82b8867fb98...
authenticator
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
cipher: 5e944cb16b72c6cb12b830b91e83ca84b3b7eadfb364e7da...
req-body
Padding: 0
kdc-options: 5001 (forwardable, proxiable, canonicalize)
0...  = reserved: False
.1..  = forwardable: True
..0.  = forwarded: False
...1

Re: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails

2017-05-08 Thread Christopher Lamb


Hi all

I can now retrieve the Tgt from the creds-cache, and request a Sgt. However
I am now bouncing between 2 errors. "ERR BAD OPTION" and "ERR GENERIC".

If I create the Tgt with the clientPrincipal, the request is rejected by
the KDC with "ERR BAD OPTION".

Examining the request with Wireshark shows a cname element in the req-body.
This is not present in successful requests via GSS-API.

cname
name-type: kRB5-NT-PRINCIPAL (1)
cname-string: 1 item
CNameString: lamb

The KDC log shows "TGT NOT PROXIABLE:" for the failed request.


On the other hand, if I fill the clientPrincipal on the Tgt with null the
request is rejected by the KDC with "ERR GENERIC".

The cname element is no longer present in the request body (which now looks
identical that made by GSS-API).

The KDC logs show "ASN.1 structure is missing a required field". I suspect
this refers to the encrypted "app-req/authenticator/cname",
which debugging shows is now null!


private TgtTicket retrieveCachedTicket(File ccacheFile) throws KrbException
{

Ticket ticket = null;
PrincipalName clientPrincipal = null;
EncAsRepPart encKdcRepPart = null;

if (ccacheFile.exists() && ccacheFile.canRead()) {
CredentialCache cCache = new CredentialCache();
try {
cCache.load(ccacheFile);

List credentials = cCache.getCredentials();

for (Credential cred : credentials) {
//we only want a tgt
if (cred.getServerName().toString().startsWith
("krbtgt")) {
ticket = cred.getTicket();
clientPrincipal = cred.getClientName();

encKdcRepPart = new EncAsRepPart();

encKdcRepPart.setAuthTime(cred.getAuthTime
());
encKdcRepPart.setCaddr
(cred.getClientAddresses());

encKdcRepPart.setEndTime(cred.getEndTime());

encKdcRepPart.setFlags(cred.getTicketFlags
());
encKdcRepPart.setKey(cred.getKey());

encKdcRepPart.setRenewTill(cred.getRenewTill
());

encKdcRepPart.setSname(cred.getServerName());

encKdcRepPart.setSrealm(cred.getServerName
().getRealm());

encKdcRepPart.setStartTime(cred.getStartTime
());
}
}

} catch (IOException e) {
throw new KrbException("Failed to load credentials", e);
}
} else {
throw new IllegalArgumentException("Invalid ccache file, "
+ "does not exist, or is not readable: " +
ccacheFile.getAbsolutePath());
}
return new TgtTicket(ticket, encKdcRepPart, clientPrincipal);
}


private void getKerbyServiceTicket() {
try {
File confFileDir = new File
("/home/lamb/OTMS/kerberosTesting/");
KrbClient krbClient = new KrbClient(confFileDir);

krbClient.setKdcHost("kdc.acme.com");
krbClient.setAllowUdp(true);
krbClient.setAllowTcp(true);
krbClient.setKdcUdpPort(88);
krbClient.setKdcTcpPort(88);
krbClient.init();

File credsCache = new File("/tmp/krb5cc_9337");

TgtTicket tgtTicket = retrieveCachedTicket(credsCache);

KOptions requestOptions = new KOptions();
requestOptions.add(KrbKdcOption.PROXIABLE, true);
requestOptions.add(KrbKdcOption.FORWARDABLE);
requestOptions.add(KrbKdcOption.CANONICALIZE, true);
requestOptions.add(KrbKdcOption.RENEWABLE_OK, false);
requestOptions.add(KrbOption.USE_TGT, tgtTicket);

requestOptions.add(KrbOption.SERVER_PRINCIPAL,
"HTTP/app-srv.acme@acme.com");

SgtTicket sgtTicket = krbClient.requestSgt(requestOptions);


} catch (KrbException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

}

Rejected Request "BAD OPTION":

tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e82023b30820237a003020105a10302010ea2070305...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 
0...  = reserved: False

Re: Questions about the release

2017-05-08 Thread Emmanuel Lécharny



Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> I don't think we need the Mockito notice as it's a test dependency, right?

right.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

2017-05-08 Thread Colm O hEigeartaigh

I don't think we need the Mockito notice as it's a test dependency, right?

Colm.

On Mon, May 8, 2017 at 3:02 PM, Colm O hEigeartaigh 
wrote:

> Actually, scratch that, it's fine to have the NOTICE file with the
> dependency information in the source as well.
>
> Colm.
>
> On Mon, May 8, 2017 at 2:50 PM, Colm O hEigeartaigh 
> wrote:
>
>> Thanks Emmanuel! So if I understand correctly, the changes that were made
>> to the NOTICE file in Kerby are incorrect:
>>
>> https://github.com/apache/directory-kerby/blob/trunk/NOTICE
>>
>> Instead, the NOTICE file should just have the standard Apache bit.
>> However, we need to update the distribution source code to include the
>> NOTICE file with the added dependencies etc. Is this correct?
>>
>> Colm.
>>
>> On Mon, May 8, 2017 at 2:21 PM, Emmanuel Lécharny 
>> wrote:
>>
>>>
>>>
>>> Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
>>> > On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
>>> >>
>>> >> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>>> >>> Hi Emmanuel,
>>> >>>
>>> >>> Is there a wiki page or something that you are aware of at Apache
>>> that
>>> >>> clearly lays out what the obligations of projects are for licenses +
>>> notice
>>> >>> files for third party dependencies? It's something I've yet to
>>> clearly wrap
>>> >>> my head around.
>>> >> I think the page is the one pointed out by Stefan :
>>> >>
>>> >> https://www.apache.org/dev/licensing-howto.html#bundled-vs-n
>>> on-bundled
>>> >>
>>> >> The thing is that it's not really clear to me too, because there is no
>>> >> example on this page.
>>> > Here is another one, that makes it IMHO clear that the source N
>>> should
>>> > not include any information about dependencies:
>>> >
>>> > "LICENSE and NOTICE MUST NOT provide unnecessary information about
>>> > materials which are not bundled in the package, such as separately
>>> > downloaded dependencies."
>>> >
>>> > https://www.apache.org/legal/release-policy.html#licensing-d
>>> ocumentation
>>> >
>>> >> The logic is the following : we are distributing packages (either
>>> >> sources or bianeis - for convenience, as The ASF is only required to
>>> >> deliver source packages for the users to build them -), and we *must*
>>> >> not give an opportinuty for our users to make a mistake and embed an
>>> >> incompatible component, or forget to add a required notice or license
>>> in
>>> >> their own packages, putting them at risk of being sued because of
>>> that.
>>> >>
>>> >> We can think that if a company is going to use our packages should do
>>> >> their due diligence, but that is putting too much of a burden on them.
>>> >> More important, it would be very bad PR for The ASF if we were to
>>> forgot
>>> >> some of teh required N
>>> > I agree with you. But I think it's two differenct cases:
>>> >
>>> > 1) The content of a distributed package.
>>> > 1a) If the package only contains source code witten by ASF committers
>>> or
>>> > the compiled class files then the minimal N applies. (Note: this
>>> would
>>> > probably not apply if we would code against an API of an GPL library,
>>> > that's why it's not allowed in ASF projects).
>>> > 1b) If some source code was borrowed e.g. from some 3rd party licensed
>>> > under MIT then we need to include that license and copyright notice.
>>> > 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
>>> > uber jars or binary distribution or installer) then all required N of
>>> > the bundled artifacts have to be added.
>>>
>>> On the same page, as soon as we are talking about source package.
>>>
>>> >
>>> > 2) The dependencies. As long as they are not bundled then they must not
>>> > be added to N
>>> correct.
>>>
>>> >  But of course it's our duty to make sure that all used
>>> > dependencies are compatible to ALv2. And we should be nice to our users
>>> > and list the dependencies. And in fact we do that :). All the Maven
>>> > generated jars contain a META-INF/DEPENDENCIES file with all
>>> > dependencies and its licenses listed. And the Maven generated source
>>> zip
>>> > also containse a DEPENDENCIES file The only issue I see is that the
>>> > Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
>>> > empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
>>> > looks fine). It's probably because of the multi-module build, but maybe
>>> > we can tune the Maven release build to include all dependencies for the
>>> > whole project.
>>> >
>>> >> So what does it mean for Kerby, specifically ? Let's check teh
>>> different
>>> >> use cases...
>>> >>
>>> >> 1) We are distributing sources only
>>> >>
>>> >> Ok, so we basically don't distribute any binary (libs or exe). Our
>>> users
>>> >> *must* build Kerby if they want to use one of the packages, or
>>> >> copy/paste kerby's code in their one code. Are we safe ? Not that
>>> much,
>>> >> as building the packages may pull some external dependencies

Re: MIT Kerberos compatibility

2017-05-08 Thread Marc de Lignie


Hi Chris, Jiajia, Kai,

Thanks for your additional suggestions. In the mean time I can confirm 
my test working on a Centos 6.x system, see logs below, that is with Mit 
Kerberos installed and the MitIssueTest.


So, there must be something strange on my Ubuntu Xenial + Mate system 
(maybe something silly as host resolution); that is for me to find out. 
At least I can compare a failing system with a working system now.


Cheers,Marc

$ python 
kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerberos/kerb/server/MitIssueTest.py
[26558] 1494229795.344270: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.344941: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.345472: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.346300: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.346911: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.347490: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.348050: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.348559: Retrieving dran...@test.com -> 
krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found

kerberos.authGSSClientInit successful
[26558] 1494229795.350166: Getting credentials dran...@test.com -> 
test-service/localhost@ using ccache 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
[26558] 1494229795.350278: Retrieving dran...@test.com -> 
test-service/localhost@ from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 
-1765328243/Matching credential not found
[26558] 1494229795.350332: Retrying dran...@test.com -> 
test-service/localh...@test.com with result: -1765328243/Matching 
credential not found
[26558] 1494229795.350349: Server has referral realm; starting with 
test-service/localh...@test.com
[26558] 1494229795.350402: Retrieving dran...@test.com -> 
krbtgt/test@test.com from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 0/Success
[26558] 1494229795.350416: Found cached TGT for service realm: 
dran...@test.com -> krbtgt/test@test.com
[26558] 1494229795.350431: Requesting tickets for 
test-service/localh...@test.com, referrals on
[26558] 1494229795.350519: Generated subkey for TGS request: 
aes128-cts/F635
[26558] 1494229795.350541: etypes requested in TGS request: aes256-cts, 
aes128-cts, des3-cbc-sha1, rc4-hmac

[26558] 1494229795.350919: Sending request (599 bytes) to TEST.COM
[26558] 1494229795.352645: Resolving hostname localhost
[26558] 1494229795.352836: Initiating TCP connection to stream ::1:43227
[26558] 1494229795.353888: Terminating TCP connection to stream ::1:43227
[26558] 1494229795.353935: Initiating TCP connection to stream 
127.0.0.1:43227

[26558] 1494229795.356311: Sending TCP request to stream 127.0.0.1:43227
[26558] 1494229795.416195: Received answer from stream 127.0.0.1:43227
[26558] 1494229795.730533: Response was not from master KDC
[26558] 1494229795.730754: TGS reply didn't decode with subkey; trying 
session key (
[26558] 1494229795.730858: TGS reply is for dran...@test.com -> 
test-service/localh...@test.com with session key aes128-cts/B24D

[26558] 1494229795.730910: TGS request result: 0/Success
[26558] 1494229795.730919: Received creds for desired service 
test-service/localh...@test.com
[26558] 1494229795.730935: Removing dran...@test.com -> 
test-service/localhost@ from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
[26558] 1494229795.730947: Storing dran...@test.com -> 
test-service/localhost@ in 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
[26558] 1494229795.731216: Also storing dran...@test.com -> 
test-service/localh...@test.com based on ticket
[26558] 1494229795.731231: Removing dran...@test.com -> 
test-service/localh...@test.com from

Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Christopher Lamb


Hi Kai

With the following code I can successfully retrieve a TGT from my existing
credential cache and use it to request a service ticket!.

Unfortunately the Service Ticket Request is currently failing with "KDC
cannot accommodate requested option".


private TgtTicket retrieveCachedTicket(File ccacheFile) throws KrbException
{

Ticket ticket = null;
PrincipalName clientPrincipal = null;
EncAsRepPart encKdcRepPart = null;

if (ccacheFile.exists() && ccacheFile.canRead()) {
CredentialCache cCache = new CredentialCache();
try {
cCache.load(ccacheFile);

List credentials = cCache.getCredentials();

for (Credential cred : credentials) {
//we only want a tgt
if (cred.getServerName().toString().startsWith
("krbtgt")) {
ticket = cred.getTicket();
clientPrincipal = cred.getClientName();

encKdcRepPart = new EncAsRepPart();

encKdcRepPart.setAuthTime(cred.getAuthTime
());
encKdcRepPart.setCaddr
(cred.getClientAddresses());

encKdcRepPart.setEndTime(cred.getEndTime());

encKdcRepPart.setFlags(cred.getTicketFlags
());
encKdcRepPart.setKey(cred.getKey());
//encKdcRepPart.setKeyExpiration(); //no
method to get from cred
//encKdcRepPart.setLastReq();   
//no method to
get from cred
//encKdcRepPart.setNonce(); 
//no method to get
from cred

encKdcRepPart.setRenewTill(cred.getRenewTill
());

encKdcRepPart.setSname(cred.getServerName());

encKdcRepPart.setSrealm(cred.getServerName
().getRealm());

encKdcRepPart.setStartTime(cred.getStartTime
());
}
}

} catch (IOException e) {
throw new KrbException("Failed to load credentials", e);
}
} else {
throw new IllegalArgumentException("Invalid ccache file, "
+ "does not exist, or is not readable: " +
ccacheFile.getAbsolutePath());
}
return new TgtTicket(ticket, encKdcRepPart, clientPrincipal);
}


private void getKerbyServiceTicket() {
try {
File confFileDir = new File
("/home/lamb/OTMS/kerberosTesting/");
KrbClient krbClient = new KrbClient(confFileDir);

krbClient.setKdcHost("kdc.acme.com");
krbClient.setAllowUdp(true);
krbClient.setAllowTcp(true);
krbClient.setKdcUdpPort(88);
krbClient.setKdcTcpPort(88);
krbClient.init();

File credsCache = new File("/tmp/krb5cc_9337");

TgtTicket tgtTicket = retrieveCachedTicket(credsCache);

KOptions requestOptions = new KOptions();
requestOptions.add(KrbKdcOption.PROXIABLE);
requestOptions.add(KrbKdcOption.FORWARDABLE);
requestOptions.add(KrbKdcOption.RENEWABLE_OK);
requestOptions.add(KrbOption.USE_TGT, tgtTicket);
requestOptions.add(KrbOption.SERVER_PRINCIPAL,
"HTTP/app-srv.acme@acme.com");

SgtTicket sgtTicket = krbClient.requestSgt(requestOptions);


} catch (KrbException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

}

Below are extracts from the KDC logs for a failed request from my
kerb-client code above, and 2 successful requests from GSS-API


Rejected request from Java kerby kerb-client
94117:May 08 17:16:26 kdc.acme.com krb5kdc[2177](info): TGS_REQ (3 etypes
{23 18 17}) 9.164.27.87: TGT NOT PROXIABLE: authtime 0,  l...@acme.com for
HTTP/app-srv.acme@acme.com, KDC can't fulfill requested option

Successful request from Java GSS-API
77320:May 07 08:51:56 kdc.acme.com krb5kdc[2177](info): TGS_REQ (4 etypes
{18 17 16 23}) 9.83.236.240: ISSUE: authtime 1494139147, etypes {rep=18
tkt=18 ses=18}, l...@acme.com for HTTP/app-srv.acme@acme.com

Successful request from Python GSS-API
94221:May 08 17:24:18 kdc.acme.com krb5kdc[2177](info): TGS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 9.164.27.87: ISSUE: authtime 1494256163, etypes
{rep=18 tkt=18 ses=18}, l...@acme.com for HTTP/app-srv.acme@acme.com


Cheers

Chris






From:   "Zheng, Kai"

Re: Questions about the release

2017-05-08 Thread Colm O hEigeartaigh

Thanks Emmanuel! So if I understand correctly, the changes that were made
to the NOTICE file in Kerby are incorrect:

https://github.com/apache/directory-kerby/blob/trunk/NOTICE

Instead, the NOTICE file should just have the standard Apache bit. However,
we need to update the distribution source code to include the NOTICE file
with the added dependencies etc. Is this correct?

Colm.

On Mon, May 8, 2017 at 2:21 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
> > On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
> >>
> >> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
> >>> Hi Emmanuel,
> >>>
> >>> Is there a wiki page or something that you are aware of at Apache that
> >>> clearly lays out what the obligations of projects are for licenses +
> notice
> >>> files for third party dependencies? It's something I've yet to clearly
> wrap
> >>> my head around.
> >> I think the page is the one pointed out by Stefan :
> >>
> >> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> >>
> >> The thing is that it's not really clear to me too, because there is no
> >> example on this page.
> > Here is another one, that makes it IMHO clear that the source N should
> > not include any information about dependencies:
> >
> > "LICENSE and NOTICE MUST NOT provide unnecessary information about
> > materials which are not bundled in the package, such as separately
> > downloaded dependencies."
> >
> > https://www.apache.org/legal/release-policy.html#licensing-documentation
> >
> >> The logic is the following : we are distributing packages (either
> >> sources or bianeis - for convenience, as The ASF is only required to
> >> deliver source packages for the users to build them -), and we *must*
> >> not give an opportinuty for our users to make a mistake and embed an
> >> incompatible component, or forget to add a required notice or license in
> >> their own packages, putting them at risk of being sued because of that.
> >>
> >> We can think that if a company is going to use our packages should do
> >> their due diligence, but that is putting too much of a burden on them.
> >> More important, it would be very bad PR for The ASF if we were to forgot
> >> some of teh required N
> > I agree with you. But I think it's two differenct cases:
> >
> > 1) The content of a distributed package.
> > 1a) If the package only contains source code witten by ASF committers or
> > the compiled class files then the minimal N applies. (Note: this would
> > probably not apply if we would code against an API of an GPL library,
> > that's why it's not allowed in ASF projects).
> > 1b) If some source code was borrowed e.g. from some 3rd party licensed
> > under MIT then we need to include that license and copyright notice.
> > 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
> > uber jars or binary distribution or installer) then all required N of
> > the bundled artifacts have to be added.
>
> On the same page, as soon as we are talking about source package.
>
> >
> > 2) The dependencies. As long as they are not bundled then they must not
> > be added to N
> correct.
>
> >  But of course it's our duty to make sure that all used
> > dependencies are compatible to ALv2. And we should be nice to our users
> > and list the dependencies. And in fact we do that :). All the Maven
> > generated jars contain a META-INF/DEPENDENCIES file with all
> > dependencies and its licenses listed. And the Maven generated source zip
> > also containse a DEPENDENCIES file The only issue I see is that the
> > Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
> > empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
> > looks fine). It's probably because of the multi-module build, but maybe
> > we can tune the Maven release build to include all dependencies for the
> > whole project.
> >
> >> So what does it mean for Kerby, specifically ? Let's check teh different
> >> use cases...
> >>
> >> 1) We are distributing sources only
> >>
> >> Ok, so we basically don't distribute any binary (libs or exe). Our users
> >> *must* build Kerby if they want to use one of the packages, or
> >> copy/paste kerby's code in their one code. Are we safe ? Not that much,
> >> as building the packages may pull some external dependencies and add
> >> them in the produced jars (typically, slf4j). In this case, the produced
> >> packages *must* include the embedded jars' N, if they are not fully AL
> >> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
> >> bundle may have a NOTICE file that requires us to embed it. It could be
> >> attribution, a tribute for the cat's author, or anything...)
> > Here I disagree. If the users builds it then it's not our duty to
> > provide prober N because we don't redistribute what th user builds.
>
> Let me clarify : when we distribute only source package (aka tar.gz of
> source files) then this package

Re: Questions about the release

2017-05-08 Thread Emmanuel Lécharny



Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
> On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
>>
>> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>>> Hi Emmanuel,
>>>
>>> Is there a wiki page or something that you are aware of at Apache that
>>> clearly lays out what the obligations of projects are for licenses + notice
>>> files for third party dependencies? It's something I've yet to clearly wrap
>>> my head around.
>> I think the page is the one pointed out by Stefan :
>>
>> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>
>> The thing is that it's not really clear to me too, because there is no
>> example on this page.
> Here is another one, that makes it IMHO clear that the source N should
> not include any information about dependencies:
>
> "LICENSE and NOTICE MUST NOT provide unnecessary information about
> materials which are not bundled in the package, such as separately
> downloaded dependencies."
>
> https://www.apache.org/legal/release-policy.html#licensing-documentation
>
>> The logic is the following : we are distributing packages (either
>> sources or bianeis - for convenience, as The ASF is only required to
>> deliver source packages for the users to build them -), and we *must*
>> not give an opportinuty for our users to make a mistake and embed an
>> incompatible component, or forget to add a required notice or license in
>> their own packages, putting them at risk of being sued because of that.
>>
>> We can think that if a company is going to use our packages should do
>> their due diligence, but that is putting too much of a burden on them.
>> More important, it would be very bad PR for The ASF if we were to forgot
>> some of teh required N
> I agree with you. But I think it's two differenct cases:
>
> 1) The content of a distributed package.
> 1a) If the package only contains source code witten by ASF committers or
> the compiled class files then the minimal N applies. (Note: this would
> probably not apply if we would code against an API of an GPL library,
> that's why it's not allowed in ASF projects).
> 1b) If some source code was borrowed e.g. from some 3rd party licensed
> under MIT then we need to include that license and copyright notice.
> 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
> uber jars or binary distribution or installer) then all required N of
> the bundled artifacts have to be added.

On the same page, as soon as we are talking about source package.

>
> 2) The dependencies. As long as they are not bundled then they must not
> be added to N
correct.

>  But of course it's our duty to make sure that all used
> dependencies are compatible to ALv2. And we should be nice to our users
> and list the dependencies. And in fact we do that :). All the Maven
> generated jars contain a META-INF/DEPENDENCIES file with all
> dependencies and its licenses listed. And the Maven generated source zip
> also containse a DEPENDENCIES file The only issue I see is that the
> Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
> empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
> looks fine). It's probably because of the multi-module build, but maybe
> we can tune the Maven release build to include all dependencies for the
> whole project.
>
>> So what does it mean for Kerby, specifically ? Let's check teh different
>> use cases...
>>
>> 1) We are distributing sources only
>>
>> Ok, so we basically don't distribute any binary (libs or exe). Our users
>> *must* build Kerby if they want to use one of the packages, or
>> copy/paste kerby's code in their one code. Are we safe ? Not that much,
>> as building the packages may pull some external dependencies and add
>> them in the produced jars (typically, slf4j). In this case, the produced
>> packages *must* include the embedded jars' N, if they are not fully AL
>> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
>> bundle may have a NOTICE file that requires us to embed it. It could be
>> attribution, a tribute for the cat's author, or anything...)
> Here I disagree. If the users builds it then it's not our duty to
> provide prober N because we don't redistribute what th user builds.

Let me clarify : when we distribute only source package (aka tar.gz of
source files) then this package dos not have to have any N file if we
don't embed binary components (like lib, images, whatever) in the jar,
or when we haven't copy/pasted any snippet of external code.

Now, the trick is that users will take this package and will build
binary packages out of it, and these binary packages must have the
required N files. That mean the build configuration must contain the
necessary instructions to get those required N files to be present in
the generated binary. This is what we do for ApacheDS, with the N file
present in the
installers-maven-plugin/src/main/resources/org/apache/directory/server/installers
directory. That what I meant when

Re: Questions about the release

2017-05-08 Thread Stefan Seelmann

On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
> 
> 
> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>> Hi Emmanuel,
>>
>> Is there a wiki page or something that you are aware of at Apache that
>> clearly lays out what the obligations of projects are for licenses + notice
>> files for third party dependencies? It's something I've yet to clearly wrap
>> my head around.
> 
> I think the page is the one pointed out by Stefan :
> 
> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> 
> The thing is that it's not really clear to me too, because there is no
> example on this page.

Here is another one, that makes it IMHO clear that the source N should
not include any information about dependencies:

"LICENSE and NOTICE MUST NOT provide unnecessary information about
materials which are not bundled in the package, such as separately
downloaded dependencies."

https://www.apache.org/legal/release-policy.html#licensing-documentation

> The logic is the following : we are distributing packages (either
> sources or bianeis - for convenience, as The ASF is only required to
> deliver source packages for the users to build them -), and we *must*
> not give an opportinuty for our users to make a mistake and embed an
> incompatible component, or forget to add a required notice or license in
> their own packages, putting them at risk of being sued because of that.
> 
> We can think that if a company is going to use our packages should do
> their due diligence, but that is putting too much of a burden on them.
> More important, it would be very bad PR for The ASF if we were to forgot
> some of teh required N

I agree with you. But I think it's two differenct cases:

1) The content of a distributed package.
1a) If the package only contains source code witten by ASF committers or
the compiled class files then the minimal N applies. (Note: this would
probably not apply if we would code against an API of an GPL library,
that's why it's not allowed in ASF projects).
1b) If some source code was borrowed e.g. from some 3rd party licensed
under MIT then we need to include that license and copyright notice.
1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
uber jars or binary distribution or installer) then all required N of
the bundled artifacts have to be added.

2) The dependencies. As long as they are not bundled then they must not
be added to N But of course it's our duty to make sure that all used
dependencies are compatible to ALv2. And we should be nice to our users
and list the dependencies. And in fact we do that :). All the Maven
generated jars contain a META-INF/DEPENDENCIES file with all
dependencies and its licenses listed. And the Maven generated source zip
also containse a DEPENDENCIES file The only issue I see is that the
Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
looks fine). It's probably because of the multi-module build, but maybe
we can tune the Maven release build to include all dependencies for the
whole project.

> So what does it mean for Kerby, specifically ? Let's check teh different
> use cases...
> 
> 1) We are distributing sources only
> 
> Ok, so we basically don't distribute any binary (libs or exe). Our users
> *must* build Kerby if they want to use one of the packages, or
> copy/paste kerby's code in their one code. Are we safe ? Not that much,
> as building the packages may pull some external dependencies and add
> them in the produced jars (typically, slf4j). In this case, the produced
> packages *must* include the embedded jars' N, if they are not fully AL
> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
> bundle may have a NOTICE file that requires us to embed it. It could be
> attribution, a tribute for the cat's author, or anything...)

Here I disagree. If the users builds it then it's not our duty to
provide prober N because we don't redistribute what th user builds.

> 2) We are distributing binaries
> 
> And, yes, the jars pulled from Maven *are* binaries. Again, we have to
> make sure that those binaries contain all the required N for all the
> embedded components in our jars.

If and only if 3rd party dependencies are bundled within the jar (like
an uber jar).

> 3) We are distributing installers
> 
> This is not Kerby's choice, it's ApacheDS and Studio choice, so I'll
> explain what is required for teh sake of clarity, but it wo'nt apply to
> Kerby. Installers are usually binaries that generate binaries. We have
> to verify that the installer's binaries are fully AL 2.0 compatible, and
> that the generated installers contain all the required N too.

Right, and it's lot of work to get it right ;)

> Why should we not add extraneous N files ? Because that would make our
> user's task too complex, and we don't want that.
> 
> 
> One last note about GPL/LGPL dependencies : GPL are clearly a no-no for
> us. As GPL is a

Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Zheng, Kai

Got your point. Please read credential cache utility codes and see if any API 
doing so.

Sent from iPhone

在 2017年5月8日，下午8:13，Christopher Lamb 
> 写道：


Hi Kai

Browsing further through the kerby code, I think I need the opposite of 
KrbClientBase.storeTicket(): for instance a " Public TgtTicket 
retrieveCachedTicket(File ccacheFile)"

Let me see if I can knock something together based on storeTicket()

Cheers

Chris

[Inactive hide details for "Zheng, Kai" ---08/05/2017 13:09:19---If I remember 
correctly, it first generates a cache with a TGT,]"Zheng, Kai" ---08/05/2017 
13:09:19---If I remember correctly, it first generates a cache with a TGT, then 
do the login test with the tick

From: "Zheng, Kai" >
To: "kerby@directory.apache.org" 
>
Date: 08/05/2017 13:09
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.





If I remember correctly, it first generates a cache with a TGT, then do the 
login test with the ticket cache. In your case, you would need to know where is 
the cache file and point it to Kerby client, as the test did.

Regards,
Kai

From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 7:05 PM
To: kerby@directory.apache.org
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.


Hi Kai

Thanks, example code is always best.

TicketCacheLoginTest looks like part of the answer, especially the 
storeTicket() function. However (unless I have completely misread the 
test-case), the TGT is not retrieved from the cache, it is only stored there.

In my Single-Sign-On case, the user already has a TGT, which was obtained on 
log in to the workstation (or by kinit), prior to starting my java client. I am 
assuming it should be possible for kerby to use the existing TGT.

Cheers

Chris

[Inactive hide details for "Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both 
dev list should be OK as Kerby folks are also in]"Zheng, Kai" ---08/05/2017 
12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in the 
parent one.

From: "Zheng, Kai" 
>
To: 
"kerby@directory.apache.org"
 
>
Date: 08/05/2017 12:45
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.





Hi Chris,

Both dev list should be OK as Kerby folks are also in the parent one.

I haven't read your details fully (will do it later), but would make sure if 
you have already checked out the test of TicketCacheLoginTest in the kerby code 
base. In one word, Kerby client surely can consume and use a credential cache 
generated by other tools like MIT kinit. If you see any issue, please report it.

Regards,
Kai

-Original Message-
From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 5:09 PM
To: 
kerby@directory.apache.org
Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.


Hi all

I hope this is the appropriate mailing list for this type of question. Or would 
it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API for 
a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When the 
user logs on to his workstation he is authenticated by the FreeIPA KDC, and  
gets a TGT which is cached in the default credentials cache. When he wishes to 
access services from the application server (which is a Service Principal), the 
TGT in the credentials cache is used to get a Service Ticket, which should also 
be cached in the credentials cache for future use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows 
both the TGT and the SGT in the credentials cache. But trying to do the same 
thing with Java GSS-API I ran into problems. While the Client is able to 
retrieve a Service Ticket, and thus login to the Service Principal, the SGT is 
not cached. Thus every request to the Service Principal requires KDC 
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am 
experimenting with it, but so far without success despite much debugging and 
scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an 
existing Kerberos credential cache (as

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Christopher Lamb

Hi Kai

Browsing further through the kerby code, I think I need the opposite of
KrbClientBase.storeTicket(): for instance a  " Public TgtTicket
retrieveCachedTicket(File ccacheFile)"

Let me see if I can knock something together based on storeTicket()

Cheers

Chris



From:   "Zheng, Kai" 
To: "kerby@directory.apache.org" 
Date:   08/05/2017 13:09
Subject:RE: Using Kerby kerb-client as an alternative for GSS-API for
Kerberos Single Sign On.



If I remember correctly, it first generates a cache with a TGT, then do the
login test with the ticket cache. In your case, you would need to know
where is the cache file and point it to Kerby client, as the test did.

Regards,
Kai

From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 7:05 PM
To: kerby@directory.apache.org
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for
Kerberos Single Sign On.


Hi Kai

Thanks, example code is always best.

TicketCacheLoginTest looks like part of the answer, especially the
storeTicket() function. However (unless I have completely misread the
test-case), the TGT is not retrieved from the cache, it is only stored
there.

In my Single-Sign-On case, the user already has a TGT, which was obtained
on log in to the workstation (or by kinit), prior to starting my java
client. I am assuming it should be possible for kerby to use the existing
TGT.

Cheers

Chris

[Inactive hide details for "Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris,
Both dev list should be OK as Kerby folks are also in]"Zheng, Kai"
---08/05/2017 12:45:22---Hi Chris, Both dev list should be OK as Kerby
folks are also in the parent one.

From: "Zheng, Kai" >
To: "kerby@directory.apache.org"
>
Date: 08/05/2017 12:45
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for
Kerberos Single Sign On.





Hi Chris,

Both dev list should be OK as Kerby folks are also in the parent one.

I haven't read your details fully (will do it later), but would make sure
if you have already checked out the test of TicketCacheLoginTest in the
kerby code base. In one word, Kerby client surely can consume and use a
credential cache generated by other tools like MIT kinit. If you see any
issue, please report it.

Regards,
Kai

-Original Message-
From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 5:09 PM
To: kerby@directory.apache.org
Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos
Single Sign On.


Hi all

I hope this is the appropriate mailing list for this type of question. Or
would it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API
for a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When
the user logs on to his workstation he is authenticated by the FreeIPA KDC,
and  gets a TGT which is cached in the default credentials cache. When he
wishes to access services from the application server (which is a Service
Principal), the TGT in the credentials cache is used to get a Service
Ticket, which should also be cached in the credentials cache for future
use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows
both the TGT and the SGT in the credentials cache. But trying to do the
same thing with Java GSS-API I ran into problems. While the Client is able
to retrieve a Service Ticket, and thus login to the Service Principal, the
SGT is not cached. Thus every request to the Service Principal requires KDC
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am
experimenting with it, but so far without success despite much debugging
and scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an
existing Kerberos credential cache (as opposed to a KeyTab), and to use the
TGT ticket within, and to cache new service tickets? In this case the
existing credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I
find references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be
configuring?

Thanks

Chris

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Zheng, Kai

If I remember correctly, it first generates a cache with a TGT, then do the 
login test with the ticket cache. In your case, you would need to know where is 
the cache file and point it to Kerby client, as the test did.

Regards,
Kai

From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 7:05 PM
To: kerby@directory.apache.org
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.

Hi Kai

Thanks, example code is always best.

TicketCacheLoginTest looks like part of the answer, especially the 
storeTicket() function. However (unless I have completely misread the 
test-case), the TGT is not retrieved from the cache, it is only stored there.

In my Single-Sign-On case, the user already has a TGT, which was obtained on 
log in to the workstation (or by kinit), prior to starting my java client. I am 
assuming it should be possible for kerby to use the existing TGT.

Cheers

Chris

[Inactive hide details for "Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both 
dev list should be OK as Kerby folks are also in]"Zheng, Kai" ---08/05/2017 
12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in the 
parent one.

From: "Zheng, Kai" >
To: "kerby@directory.apache.org" 
>
Date: 08/05/2017 12:45
Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.

Hi Chris,

Both dev list should be OK as Kerby folks are also in the parent one.

I haven't read your details fully (will do it later), but would make sure if 
you have already checked out the test of TicketCacheLoginTest in the kerby code 
base. In one word, Kerby client surely can consume and use a credential cache 
generated by other tools like MIT kinit. If you see any issue, please report it.

Regards,
Kai

-Original Message-
From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 5:09 PM
To: kerby@directory.apache.org
Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.

Hi all

I hope this is the appropriate mailing list for this type of question. Or would 
it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API for 
a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When the 
user logs on to his workstation he is authenticated by the FreeIPA KDC, and  
gets a TGT which is cached in the default credentials cache. When he wishes to 
access services from the application server (which is a Service Principal), the 
TGT in the credentials cache is used to get a Service Ticket, which should also 
be cached in the credentials cache for future use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows 
both the TGT and the SGT in the credentials cache. But trying to do the same 
thing with Java GSS-API I ran into problems. While the Client is able to 
retrieve a Service Ticket, and thus login to the Service Principal, the SGT is 
not cached. Thus every request to the Service Principal requires KDC 
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am 
experimenting with it, but so far without success despite much debugging and 
scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an 
existing Kerberos credential cache (as opposed to a KeyTab), and to use the TGT 
ticket within, and to cache new service tickets? In this case the existing 
credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I find 
references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx 
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be configuring?

Thanks

Chris

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Christopher Lamb

Hi Kai

Thanks, example code is always best.

TicketCacheLoginTest looks like part of the answer, especially the
storeTicket() function. However (unless I have completely misread the
test-case), the TGT is not retrieved from the cache, it is only stored
there.

In my Single-Sign-On case, the user already has a TGT, which was obtained
on log in to the workstation (or by kinit),  prior to starting my java
client. I am assuming it should be possible for kerby to use the existing
TGT.

Cheers

Chris



From:   "Zheng, Kai" 
To: "kerby@directory.apache.org" 
Date:   08/05/2017 12:45
Subject:RE: Using Kerby kerb-client as an alternative for GSS-API for
Kerberos Single Sign On.



Hi Chris,

Both dev list should be OK as Kerby folks are also in the parent one.

I haven't read your details fully (will do it later), but would make sure
if you have already checked out the test of TicketCacheLoginTest in the
kerby code base. In one word, Kerby client surely can consume and use a
credential cache generated by other tools like MIT kinit. If you see any
issue, please report it.

Regards,
Kai

-Original Message-
From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Sent: Monday, May 08, 2017 5:09 PM
To: kerby@directory.apache.org
Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos
Single Sign On.


Hi all

I hope this is the appropriate mailing list for this type of question. Or
would it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API
for a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When
the user logs on to his workstation he is authenticated by the FreeIPA KDC,
and  gets a TGT which is cached in the default credentials cache. When he
wishes to access services from the application server (which is a Service
Principal), the TGT in the credentials cache is used to get a Service
Ticket, which should also be cached in the credentials cache for future
use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows
both the TGT and the SGT in the credentials cache. But trying to do the
same thing with Java GSS-API I ran into problems. While the Client is able
to retrieve a Service Ticket, and thus login to the Service Principal, the
SGT is not cached. Thus every request to the Service Principal requires KDC
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am
experimenting with it, but so far without success despite much debugging
and scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an
existing Kerberos credential cache (as opposed to a KeyTab), and to use the
TGT ticket within, and to cache new service tickets? In this case the
existing credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I
find references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be
configuring?

Thanks

Chris

RE: MIT Kerberos compatibility

2017-05-08 Thread Zheng, Kai

Hi Marc,

Thanks for your patience. It looks to me there is some issue in Kerby with 
Heimdal compatibility. Note we haven't supported Heimdal yet. So far, Kerby is 
tested and can support these clients:
1. Oracle Java;
2. Kerby client;
3. MIT client.

Both compatibility tests with MS AD and Heimdal haven't been done yet. For 
Heimdal, I thought we can get back to this later (hope soon, a week later). 
We're pretty busy with urgent things, sorry.

Regards,
Kai

-Original Message-
From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl] 
Sent: Sunday, May 07, 2017 10:13 PM
To: kerby@directory.apache.org
Subject: Re: MIT Kerberos compatibility

Hi Jiajia and Kai,

Puzzled by the fact that the Mit Kerberos over python service ticket request 
works on Jiajia's system but not on mine. I attempted to request the service 
ticket with Mit Kerberos's kinit tool and  it worked.

This means that my issue probably lies in the kerberos python wrapper around 
the Mit Kerberos shared libs (or in the way how I use it). I tried both with 
the Debian python-kerberos package, https://pypi.python.org/pypi/kerberos and 
with https://pypi.python.org/pypi/pykerberos/1.1.14, neither of which got the 
ticket. This still makes me curious where Mac-OS gets its python kerberos 
package from :-)

Here, the kinit shell commands to reproduce my test.

cd $PROJECTROOT
WORKDIR=kerby-kerb/kerb-kdc-test/target/tmp
export KRB5_CONFIG=$WORKDIR/krb5.conf
export KRB5CCNAME=$WORKDIR/test-tkt.cc
export KRB5_TRACE=/dev/stdout

$ kinit -S test-service/localhost
[3141] 1494161999.566468: Getting initial credentials for dran...@test.com 
[3141] 1494161999.566835: Setting initial creds service to 
test-service/localhost [3141] 1494161999.566952: Sending request (168 bytes) to 
TEST.COM [3141] 1494161999.566997: Resolving hostname localhost [3141] 
1494161999.567467: Sending initial UDP request to dgram
127.0.0.1:45527
[3141] 1494161999.573494: Received answer (555 bytes) from dgram
127.0.0.1:45527
[3141] 1494161999.576791: Response was not from master KDC [3141] 
1494161999.576822: Salt derived from principal: TEST.COMdrankye [3141] 
1494161999.576824: Getting AS key, salt "TEST.COMdrankye", params ""
Password for dran...@test.com:
[3141] 1494162015.450071: AS key obtained from gak_fct: aes128-cts/0548 [3141] 
1494162015.450101: Decrypted AS reply; session key is: 
aes128-cts/4EFE
[3141] 1494162015.450103: FAST negotiation: unavailable [3141] 
1494162015.450112: Initializing 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with default princ 
dran...@test.com [3141] 1494162015.450305: Storing dran...@test.com -> 
test-service/localh...@test.com in 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc

$ klist
Ticket cache: FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
Default principal: dran...@test.com

Valid starting ExpiresService principal
07-05-17 14:59:59  08-05-17 14:59:59 test-service/localh...@test.com
 renew until 08-05-17 14:59:59

What is also notable here is that the TestKdc only produces one log message:

[nioEventLoopGroup-5-1] INFO
org.apache.kerby.kerberos.kerb.server.request.AsRequest - AS_REQ ISSUE: 
authtime 1494164956766,dran...@test.com for test-service/localh...@test.com

while in the error situation from python it produces (and not the AS_REQ
line):

[nioEventLoopGroup-5-1] INFO
org.apache.kerby.kerberos.kerb.server.request.KdcRequest - Found fast padata 
and starting to process it.
[nioEventLoopGroup-5-1] INFO
org.apache.kerby.kerberos.kerb.server.request.KdcRequest - Found fast padata 
and starting to process it.

Note also that kinit requires to give the password while in the python testcase 
it is attempted to use the tgt from the credential cache.

Maybe it also useful to restate my target: I want to authenticate a python 
client towards a service using GSSAPI with SASL (the service being 
gremlin-server from the Apache Tinkerpop project). So I want to get the service 
ticket using GSSAPI and an existing tgt from the credential cache.

Any additional hints are welcome, good luck with the Kerby GA release.

Marc

Op 05-05-17 om 22:12 schreef Marc de Lignie:
> Hi Jiajia,
>
> Thanks for the netty config option. This indeed helped to get rid of 
> the udp errors, but did not help in getting the service ticket (final 
> error message remains the same).
>
> I also noticed that I get the same error from the python console 
> whether I specify the right service name or some service name for 
> which no service principal exists in the TestKdc.
>
> I did not succeed in getting mvn tst to print the debug logging of the 
> various kdc classes involved.
>
> Did you check with klist whether drankye's credential cache contains 
> the service ticket for test-service?
>
> Cheers,Marc
>
>
> Op 04-05-17 om 14:55 schreef Li, Jiajia:
>> Hi Marc,
>> I try to run your test(through applying your patch in the trunk) , I 
>> think it's success now.  Could you take some time to check about it?
>> Here is

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Zheng, Kai

Hi Chris,

Both dev list should be OK as Kerby folks are also in the parent one.

I haven't read your details fully (will do it later), but would make sure if 
you have already checked out the test of TicketCacheLoginTest in the kerby code 
base. In one word, Kerby client surely can consume and use a credential cache 
generated by other tools like MIT kinit. If you see any issue, please report 
it. 

Regards,
Kai

-Original Message-
From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] 
Sent: Monday, May 08, 2017 5:09 PM
To: kerby@directory.apache.org
Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.


Hi all

I hope this is the appropriate mailing list for this type of question. Or would 
it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API for 
a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When the 
user logs on to his workstation he is authenticated by the FreeIPA KDC, and  
gets a TGT which is cached in the default credentials cache. When he wishes to 
access services from the application server (which is a Service Principal), the 
TGT in the credentials cache is used to get a Service Ticket, which should also 
be cached in the credentials cache for future use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows 
both the TGT and the SGT in the credentials cache. But trying to do the same 
thing with Java GSS-API I ran into problems. While the Client is able to 
retrieve a Service Ticket, and thus login to the Service Principal, the SGT is 
not cached. Thus every request to the Service Principal requires KDC 
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am 
experimenting with it, but so far without success despite much debugging and 
scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an 
existing Kerberos credential cache (as opposed to a KeyTab), and to use the TGT 
ticket within, and to cache new service tickets? In this case the existing 
credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I find 
references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx 
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be configuring?

Thanks

Chris

RE: MIT Kerberos compatibility

2017-05-08 Thread Zheng, Kai

Thanks Colm for the confirm!

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, May 08, 2017 6:36 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: MIT Kerberos compatibility

Hi Kai,
No I think it wasn't caused by recent changes. It's fine to target it for the 
next release. I will call another vote for 1.0.0 as soon as we get the go ahead 
from Emmanuel.
Colm.

On Mon, May 8, 2017 at 11:32 AM, Zheng, Kai 
> wrote:
Hi Colm,

Did you aware it's caused by any recent changes? It looks to me not. How serve 
is it? It appears in some case in the WSS4J tests. We have work around, using 
the Netty one. I'd suggest we target it for next minor release, like 1.1.0 or 
1.0.1 so we have enough bandwidth to investigate and improve the default 
transport. We probably shouldn't introduce more changes to get the release out. 
Note please prefer to use the TCP transport over the UDP one, in today's world.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org]
Sent: Monday, May 08, 2017 6:19 PM
To: kerby@directory.apache.org
Subject: Re: MIT Kerberos compatibility
OK I have created a JIRA and attached a patch that you have to apply to the
Apache WSS4J project to reproduce the error. If you uncomment the line that
uses Netty then the tests all work perfectly. The tests appear to work fine
when run in isolation, it's only when you run a few of them after one
another that you can see the failures.

Please let me know if you have any difficulty in reproducing, thanks!

Colm.

On Mon, May 8, 2017 at 11:08 AM, Zheng, Kai 
> wrote:

> Hi Colm,
>
> Sure, please do it. Could you review my change and see how it would cause
> the new failures? Any difference between the failed GSS tests and the Kerby
> GSS tests?
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org]
> Sent: Monday, May 08, 2017 5:42 PM
> To: Zheng, Kai >
> Cc: kerby@directory.apache.org
> Subject: Re: MIT Kerberos compatibility
>
> Hi Kai,
>
> Your changes fixed the error message I was seeing. However, I now see
> another problem when I run a few GSS client tests in a row:
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=localhost UDP:42665, timeout=3, number of
> retries =3, #bytes=245
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =1,
> #bytes=245
> SocketTimeOutException with attempt: 1
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =2,
> #bytes=245
> >>> KrbKdcReq send: error trying localhost:42665
> java.net.PortUnreachableException: ICMP Port Unreachable
>
> Do you want me to create a JIRA + attach a test-case?
>
> Colm.
>
> On Sat, May 6, 2017 at 2:01 AM, Zheng, Kai 
> > wrote:
>
> > I haven't repeated the issue but revisited the codes again and made
> > improvements. Would you check it out? Thanks!
> >
> > Sent from iPhone
> >
> > > 在 2017年5月6日，上午6:28，Zheng, Kai 
> > > > 写道：
> > >
> > > Thanks colm for the clarification and it sounds an issue we need to
> > address. I will investigate it soon.
> > >
> > > Sent from iPhone
> > >
> > >> 在 2017年5月6日，上午2:14，Colm O hEigeartaigh 
> > >> > 写道：
> > >>
> > >> Hi Kai,
> > >>
> > >> If I enable UDP with the default Transport, I can get a ticket fine
> > using
> > >> kinit. However then the following error pops up in the window I'm
> > running
> > >> Kerby in (as a test):
> > >>
> > >> Exception in thread "Thread-1" java.lang.RuntimeException: Error
> > >> occured while checking udp connections
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:105)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > access$000(KdcNetwork.java:39)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
> > run(KdcNetwork.java:75)
> > >>   at java.lang.Thread.run(Thread.java:748)
> > >> Caused by: java.nio.channels.ClosedChannelException
> > >>   at
> > >> sun.nio.ch.DatagramChannelImpl.ensureOpen(
> DatagramChannelImpl.java:320)
> > >>   at sun.nio.ch.DatagramChannelImpl.receive(
> > DatagramChannelImpl.java:331)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > checkUdpMessage(KdcNetwork.java:132)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:101)
> > >>
> > >> Colm.
> > >>
> > >>
> > >>> On Fri, May 5, 2017 at 5:56 PM,

Re: MIT Kerberos compatibility

2017-05-08 Thread Colm O hEigeartaigh

Hi Kai,

No I think it wasn't caused by recent changes. It's fine to target it for
the next release. I will call another vote for 1.0.0 as soon as we get the
go ahead from Emmanuel.

Colm.

On Mon, May 8, 2017 at 11:32 AM, Zheng, Kai  wrote:

> Hi Colm,
>
> Did you aware it's caused by any recent changes? It looks to me not. How
> serve is it? It appears in some case in the WSS4J tests. We have work
> around, using the Netty one. I'd suggest we target it for next minor
> release, like 1.1.0 or 1.0.1 so we have enough bandwidth to investigate and
> improve the default transport. We probably shouldn't introduce more changes
> to get the release out. Note please prefer to use the TCP transport over
> the UDP one, in today's world.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, May 08, 2017 6:19 PM
> To: kerby@directory.apache.org
> Subject: Re: MIT Kerberos compatibility
>
> OK I have created a JIRA and attached a patch that you have to apply to the
> Apache WSS4J project to reproduce the error. If you uncomment the line that
> uses Netty then the tests all work perfectly. The tests appear to work fine
> when run in isolation, it's only when you run a few of them after one
> another that you can see the failures.
>
> Please let me know if you have any difficulty in reproducing, thanks!
>
> Colm.
>
> On Mon, May 8, 2017 at 11:08 AM, Zheng, Kai  wrote:
>
> > Hi Colm,
> >
> > Sure, please do it. Could you review my change and see how it would cause
> > the new failures? Any difference between the failed GSS tests and the
> Kerby
> > GSS tests?
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Monday, May 08, 2017 5:42 PM
> > To: Zheng, Kai 
> > Cc: kerby@directory.apache.org
> > Subject: Re: MIT Kerberos compatibility
> >
> > Hi Kai,
> >
> > Your changes fixed the error message I was seeing. However, I now see
> > another problem when I run a few GSS client tests in a row:
> >
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=localhost UDP:42665, timeout=3, number of
> > retries =3, #bytes=245
> > >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =1,
> > #bytes=245
> > SocketTimeOutException with attempt: 1
> > >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =2,
> > #bytes=245
> > >>> KrbKdcReq send: error trying localhost:42665
> > java.net.PortUnreachableException: ICMP Port Unreachable
> >
> > Do you want me to create a JIRA + attach a test-case?
> >
> > Colm.
> >
> > On Sat, May 6, 2017 at 2:01 AM, Zheng, Kai  wrote:
> >
> > > I haven't repeated the issue but revisited the codes again and made
> > > improvements. Would you check it out? Thanks!
> > >
> > > Sent from iPhone
> > >
> > > > 在 2017年5月6日，上午6:28，Zheng, Kai  写道：
> > > >
> > > > Thanks colm for the clarification and it sounds an issue we need to
> > > address. I will investigate it soon.
> > > >
> > > > Sent from iPhone
> > > >
> > > >> 在 2017年5月6日，上午2:14，Colm O hEigeartaigh  写道：
> > > >>
> > > >> Hi Kai,
> > > >>
> > > >> If I enable UDP with the default Transport, I can get a ticket fine
> > > using
> > > >> kinit. However then the following error pops up in the window I'm
> > > running
> > > >> Kerby in (as a test):
> > > >>
> > > >> Exception in thread "Thread-1" java.lang.RuntimeException: Error
> > > >> occured while checking udp connections
> > > >>   at
> > > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > > KdcNetwork.java:105)
> > > >>   at
> > > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > > access$000(KdcNetwork.java:39)
> > > >>   at
> > > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
> > > run(KdcNetwork.java:75)
> > > >>   at java.lang.Thread.run(Thread.java:748)
> > > >> Caused by: java.nio.channels.ClosedChannelException
> > > >>   at
> > > >> sun.nio.ch.DatagramChannelImpl.ensureOpen(
> > DatagramChannelImpl.java:320)
> > > >>   at sun.nio.ch.DatagramChannelImpl.receive(
> > > DatagramChannelImpl.java:331)
> > > >>   at
> > > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > > checkUdpMessage(KdcNetwork.java:132)
> > > >>   at
> > > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > > KdcNetwork.java:101)
> > > >>
> > > >> Colm.
> > > >>
> > > >>
> > > >>> On Fri, May 5, 2017 at 5:56 PM, Zheng, Kai 
> > > wrote:
> > > >>>
> > > >>> Colm, did you see udp problem now instead? I'm a little confused.
> > > >>> Udp
> > > is
> > > >>> sure supported but may not be enabled by default, which should be
> > > >>> okay, imo. Thanks.
> > > >>>
> > > >>> Sent from iPhone
> > > >>>
> > >  在 2017年5月6日，上午12:02，Colm O hEigeartaigh  写道：
>

RE: MIT Kerberos compatibility

2017-05-08 Thread Zheng, Kai

Hi Colm,

Did you aware it's caused by any recent changes? It looks to me not. How serve 
is it? It appears in some case in the WSS4J tests. We have work around, using 
the Netty one. I'd suggest we target it for next minor release, like 1.1.0 or 
1.0.1 so we have enough bandwidth to investigate and improve the default 
transport. We probably shouldn't introduce more changes to get the release out. 
Note please prefer to use the TCP transport over the UDP one, in today's world. 

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, May 08, 2017 6:19 PM
To: kerby@directory.apache.org
Subject: Re: MIT Kerberos compatibility

OK I have created a JIRA and attached a patch that you have to apply to the
Apache WSS4J project to reproduce the error. If you uncomment the line that
uses Netty then the tests all work perfectly. The tests appear to work fine
when run in isolation, it's only when you run a few of them after one
another that you can see the failures.

Please let me know if you have any difficulty in reproducing, thanks!

Colm.

On Mon, May 8, 2017 at 11:08 AM, Zheng, Kai  wrote:

> Hi Colm,
>
> Sure, please do it. Could you review my change and see how it would cause
> the new failures? Any difference between the failed GSS tests and the Kerby
> GSS tests?
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, May 08, 2017 5:42 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: MIT Kerberos compatibility
>
> Hi Kai,
>
> Your changes fixed the error message I was seeing. However, I now see
> another problem when I run a few GSS client tests in a row:
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=localhost UDP:42665, timeout=3, number of
> retries =3, #bytes=245
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =1,
> #bytes=245
> SocketTimeOutException with attempt: 1
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =2,
> #bytes=245
> >>> KrbKdcReq send: error trying localhost:42665
> java.net.PortUnreachableException: ICMP Port Unreachable
>
> Do you want me to create a JIRA + attach a test-case?
>
> Colm.
>
> On Sat, May 6, 2017 at 2:01 AM, Zheng, Kai  wrote:
>
> > I haven't repeated the issue but revisited the codes again and made
> > improvements. Would you check it out? Thanks!
> >
> > Sent from iPhone
> >
> > > 在 2017年5月6日，上午6:28，Zheng, Kai  写道：
> > >
> > > Thanks colm for the clarification and it sounds an issue we need to
> > address. I will investigate it soon.
> > >
> > > Sent from iPhone
> > >
> > >> 在 2017年5月6日，上午2:14，Colm O hEigeartaigh  写道：
> > >>
> > >> Hi Kai,
> > >>
> > >> If I enable UDP with the default Transport, I can get a ticket fine
> > using
> > >> kinit. However then the following error pops up in the window I'm
> > running
> > >> Kerby in (as a test):
> > >>
> > >> Exception in thread "Thread-1" java.lang.RuntimeException: Error
> > >> occured while checking udp connections
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:105)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > access$000(KdcNetwork.java:39)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
> > run(KdcNetwork.java:75)
> > >>   at java.lang.Thread.run(Thread.java:748)
> > >> Caused by: java.nio.channels.ClosedChannelException
> > >>   at
> > >> sun.nio.ch.DatagramChannelImpl.ensureOpen(
> DatagramChannelImpl.java:320)
> > >>   at sun.nio.ch.DatagramChannelImpl.receive(
> > DatagramChannelImpl.java:331)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > checkUdpMessage(KdcNetwork.java:132)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:101)
> > >>
> > >> Colm.
> > >>
> > >>
> > >>> On Fri, May 5, 2017 at 5:56 PM, Zheng, Kai 
> > wrote:
> > >>>
> > >>> Colm, did you see udp problem now instead? I'm a little confused.
> > >>> Udp
> > is
> > >>> sure supported but may not be enabled by default, which should be
> > >>> okay, imo. Thanks.
> > >>>
> > >>> Sent from iPhone
> > >>>
> >  在 2017年5月6日，上午12:02，Colm O hEigeartaigh  写道：
> > 
> >  That's probably it. Why does the default transport not support
> >  UDP in
> > >>> Kerby?
> > 
> >  Colm.
> > 
> > > On Fri, May 5, 2017 at 4:54 PM, Li, Jiajia 
> > wrote:
> > >
> > > Are you sure add kdc_allow_udp = false in kdc.conf?
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -Original Message-
> > > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > > Sent: Friday, May 5, 2017 11:41 PM
> > >

Re: MIT Kerberos compatibility

2017-05-08 Thread Colm O hEigeartaigh

OK I have created a JIRA and attached a patch that you have to apply to the
Apache WSS4J project to reproduce the error. If you uncomment the line that
uses Netty then the tests all work perfectly. The tests appear to work fine
when run in isolation, it's only when you run a few of them after one
another that you can see the failures.

Please let me know if you have any difficulty in reproducing, thanks!

Colm.

On Mon, May 8, 2017 at 11:08 AM, Zheng, Kai  wrote:

> Hi Colm,
>
> Sure, please do it. Could you review my change and see how it would cause
> the new failures? Any difference between the failed GSS tests and the Kerby
> GSS tests?
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, May 08, 2017 5:42 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: MIT Kerberos compatibility
>
> Hi Kai,
>
> Your changes fixed the error message I was seeing. However, I now see
> another problem when I run a few GSS client tests in a row:
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=localhost UDP:42665, timeout=3, number of
> retries =3, #bytes=245
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =1,
> #bytes=245
> SocketTimeOutException with attempt: 1
> >>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =2,
> #bytes=245
> >>> KrbKdcReq send: error trying localhost:42665
> java.net.PortUnreachableException: ICMP Port Unreachable
>
> Do you want me to create a JIRA + attach a test-case?
>
> Colm.
>
> On Sat, May 6, 2017 at 2:01 AM, Zheng, Kai  wrote:
>
> > I haven't repeated the issue but revisited the codes again and made
> > improvements. Would you check it out? Thanks!
> >
> > Sent from iPhone
> >
> > > 在 2017年5月6日，上午6:28，Zheng, Kai  写道：
> > >
> > > Thanks colm for the clarification and it sounds an issue we need to
> > address. I will investigate it soon.
> > >
> > > Sent from iPhone
> > >
> > >> 在 2017年5月6日，上午2:14，Colm O hEigeartaigh  写道：
> > >>
> > >> Hi Kai,
> > >>
> > >> If I enable UDP with the default Transport, I can get a ticket fine
> > using
> > >> kinit. However then the following error pops up in the window I'm
> > running
> > >> Kerby in (as a test):
> > >>
> > >> Exception in thread "Thread-1" java.lang.RuntimeException: Error
> > >> occured while checking udp connections
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:105)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > access$000(KdcNetwork.java:39)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
> > run(KdcNetwork.java:75)
> > >>   at java.lang.Thread.run(Thread.java:748)
> > >> Caused by: java.nio.channels.ClosedChannelException
> > >>   at
> > >> sun.nio.ch.DatagramChannelImpl.ensureOpen(
> DatagramChannelImpl.java:320)
> > >>   at sun.nio.ch.DatagramChannelImpl.receive(
> > DatagramChannelImpl.java:331)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> > checkUdpMessage(KdcNetwork.java:132)
> > >>   at
> > >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> > KdcNetwork.java:101)
> > >>
> > >> Colm.
> > >>
> > >>
> > >>> On Fri, May 5, 2017 at 5:56 PM, Zheng, Kai 
> > wrote:
> > >>>
> > >>> Colm, did you see udp problem now instead? I'm a little confused.
> > >>> Udp
> > is
> > >>> sure supported but may not be enabled by default, which should be
> > >>> okay, imo. Thanks.
> > >>>
> > >>> Sent from iPhone
> > >>>
> >  在 2017年5月6日，上午12:02，Colm O hEigeartaigh  写道：
> > 
> >  That's probably it. Why does the default transport not support
> >  UDP in
> > >>> Kerby?
> > 
> >  Colm.
> > 
> > > On Fri, May 5, 2017 at 4:54 PM, Li, Jiajia 
> > wrote:
> > >
> > > Are you sure add kdc_allow_udp = false in kdc.conf?
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -Original Message-
> > > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > > Sent: Friday, May 5, 2017 11:41 PM
> > > To: Li, Jiajia 
> > > Cc: kerby@directory.apache.org; Zheng, Kai
> > > ;
> > >>> mailto:
> > > m.c.delig...@xs4all.nl 
> > > Subject: Re: MIT Kerberos compatibility
> > >
> > > Sorry, it was my error, UDP was actually enabled there. But why
> > > am I
> > >>> still
> > > seeing that error message?
> > >
> > > Colm.
> > >
> > >> On Fri, May 5, 2017 at 4:39 PM, Li, Jiajia
> > >> 
> > >>> wrote:
> > >>
> > >> Hi Colm,
> > >> I also test the Kerby KDC with kerby kint and MIT kinit, and
> > >> only listen the tcp port(disable udp),

Re: MIT Kerberos compatibility

2017-05-08 Thread Colm O hEigeartaigh

Hi Kai,

Your changes fixed the error message I was seeing. However, I now see
another problem when I run a few GSS client tests in a row:

>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=localhost UDP:42665, timeout=3, number of
retries =3, #bytes=245
>>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =1,
#bytes=245
SocketTimeOutException with attempt: 1
>>> KDCCommunication: kdc=localhost UDP:42665, timeout=3,Attempt =2,
#bytes=245
>>> KrbKdcReq send: error trying localhost:42665
java.net.PortUnreachableException: ICMP Port Unreachable

Do you want me to create a JIRA + attach a test-case?

Colm.

On Sat, May 6, 2017 at 2:01 AM, Zheng, Kai  wrote:

> I haven't repeated the issue but revisited the codes again and made
> improvements. Would you check it out? Thanks!
>
> Sent from iPhone
>
> > 在 2017年5月6日，上午6:28，Zheng, Kai  写道：
> >
> > Thanks colm for the clarification and it sounds an issue we need to
> address. I will investigate it soon.
> >
> > Sent from iPhone
> >
> >> 在 2017年5月6日，上午2:14，Colm O hEigeartaigh  写道：
> >>
> >> Hi Kai,
> >>
> >> If I enable UDP with the default Transport, I can get a ticket fine
> using
> >> kinit. However then the following error pops up in the window I'm
> running
> >> Kerby in (as a test):
> >>
> >> Exception in thread "Thread-1" java.lang.RuntimeException: Error occured
> >> while checking udp connections
> >>   at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> KdcNetwork.java:105)
> >>   at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> access$000(KdcNetwork.java:39)
> >>   at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
> run(KdcNetwork.java:75)
> >>   at java.lang.Thread.run(Thread.java:748)
> >> Caused by: java.nio.channels.ClosedChannelException
> >>   at
> >> sun.nio.ch.DatagramChannelImpl.ensureOpen(DatagramChannelImpl.java:320)
> >>   at sun.nio.ch.DatagramChannelImpl.receive(
> DatagramChannelImpl.java:331)
> >>   at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> checkUdpMessage(KdcNetwork.java:132)
> >>   at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> KdcNetwork.java:101)
> >>
> >> Colm.
> >>
> >>
> >>> On Fri, May 5, 2017 at 5:56 PM, Zheng, Kai 
> wrote:
> >>>
> >>> Colm, did you see udp problem now instead? I'm a little confused. Udp
> is
> >>> sure supported but may not be enabled by default, which should be okay,
> >>> imo. Thanks.
> >>>
> >>> Sent from iPhone
> >>>
>  在 2017年5月6日，上午12:02，Colm O hEigeartaigh  写道：
> 
>  That's probably it. Why does the default transport not support UDP in
> >>> Kerby?
> 
>  Colm.
> 
> > On Fri, May 5, 2017 at 4:54 PM, Li, Jiajia 
> wrote:
> >
> > Are you sure add kdc_allow_udp = false in kdc.conf?
> >
> > Thanks
> > Jiajia
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Friday, May 5, 2017 11:41 PM
> > To: Li, Jiajia 
> > Cc: kerby@directory.apache.org; Zheng, Kai ;
> >>> mailto:
> > m.c.delig...@xs4all.nl 
> > Subject: Re: MIT Kerberos compatibility
> >
> > Sorry, it was my error, UDP was actually enabled there. But why am I
> >>> still
> > seeing that error message?
> >
> > Colm.
> >
> >> On Fri, May 5, 2017 at 4:39 PM, Li, Jiajia 
> >>> wrote:
> >>
> >> Hi Colm,
> >> I also test the Kerby KDC with kerby kint and MIT kinit, and only
> >> listen the tcp port(disable udp), both got ticket successfully. But
> I
> >> don't get the error message. Both krb.conf and kdc.conf should set
> udp
> >> to be false, udp is enabled in default.
> >>
> >> Thanks
> >> Jiajia
> >>
> >> -Original Message-
> >> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> >> Sent: Friday, May 5, 2017 11:34 PM
> >> To: kerby@directory.apache.org
> >> Cc: Zheng, Kai ; mailto:m.c.delig...@xs4all.nl
> <
> >> m.c.delig...@xs4all.nl>
> >> Subject: Re: MIT Kerberos compatibility
> >>
> >> Hi Jiajia,
> >>
> >> If UDP is disabled and we don't use Netty, I can get a token
> >> successfully via kinit. However I then see an error message in the
> >>> Kerby
> > console:
> >>
> >> Exception in thread "Thread-1" java.lang.RuntimeException: Error
> >> occured while checking udp connections
> >>  at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run(
> >> KdcNetwork.java:105)
> >>  at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.
> >> access$000(KdcNetwork.java:39)
> >>  at
> >> org.apache.kerby.kerberos.kerb.transport.KdcNetwork$1.
>

Re: Questions about the release

2017-05-08 Thread Colm O hEigeartaigh

Hi Emmanuel,

Is there a wiki page or something that you are aware of at Apache that
clearly lays out what the obligations of projects are for licenses + notice
files for third party dependencies? It's something I've yet to clearly wrap
my head around.

Colm.

On Mon, May 8, 2017 at 10:22 AM, Emmanuel Lecharny 
wrote:

> As soon as I'll beback home !
>
>
> Le lun. 8 mai 2017 à 09:27, Li, Jiajia  a écrit :
>
> > I've added the slf4j N, mockito N, netty's NOTICE, hamcrest N,
> > bouncycastle N(used by netty, but not included in it's N),
> > Jline N(used by zookeeper, but not included in it's N)
> > You can find out the NOTICE at NOTICE file, the licenses in LICENSE file
> > and license/ folder.
> >
> > I also checked the following:
> > >>> Check the google gson N files.
> > Gson is released under the Apache 2.0 license.
> >
> > >>>check the nimbus-jose-jwt N
> > The library source code is provided under the Apache 2.0 license.
> >
> > >>>nimbus-jose-jwt has itself some dependencies that requires some N
> > (potentially, that has to be checked) :
> > >>>jcip-annotations, json-smart and bcprov-jdk15on
> > jcip-annotations, json-smart are under Apache 2.0 license, and I've added
> > bouncycastle license
> >
> > And checked the transitive dependencies:
> > commons-io: AL 2.0
> > log4j: AL 2.0
> > junit: AL 2.0
> >
> > @ Emmanuel, could you review the changes?
> >
> > Thanks
> > Jiajia
> >
> >
> > -Original Message-
> > From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> > Sent: Monday, May 8, 2017 12:18 PM
> > To: kerby@directory.apache.org
> > Subject: Questions about the release
> >
> > Hi guys,
> >
> >
> > I have checked all the modules, and their dependencies. Here is the
> result
> > :
> >
> >
> > kerby-all -> test[junit, assertj-core] : OK, no N, test
> >
> >  |
> >
> >  +-- kerby-common -> [commons.io] : OK, no N, Apache
> >  +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need
> to
> > add the slf4j N
> >  +-- kerby-kerb
> >
> >  ||
> >
> >  |+-- kerb-core -> OK
> >
> >  |+-- kerb-common -> [commons.io] : OK, no N, Apache
> >  |+-- kerb-util -> test[mockito-core] : OK, no N, test
> >  |+-- kerb-crypto -> OK
> >  |+-- kerb-identity -> OK
> >  |+-- kerb-identity-test -> test, no N
> >  |+-- kerb-client -> test[mockito-core]: OK, no N, test
> >  |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
> >  |+-- kerb-kdc-test -> test, no N
> >  |+-- integration-test -> test, no N
> >  |+-- kerb-admin -> OK
> >  |+-- kerb-admin-server -> OK
> >  |+-- kerb-simplekdc -> OK
> >  |+-- kerb-client-api-all -> OK
> >  |+-- kerb-server-api-all -> OK
> >  +-- kerby-kdc -> [netty-transport, netty-handler, netty-common,
> > netty-codec, netty-buffer, slf4j-api] : Need to add the mockito mockito
> > N, add the netty's NOTICE file
> >
> >  +-- kerby-tool
> >
> >  ||
> >
> >  |+-- client-tool -> OK
> >  |+-- kdc-tool -> OK
> >
> >  +-- kerby-kdc-test  -> test, no N
> >  +-- kerby-backend
> >
> >  ||
> >
> >  |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
> >  |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
> >  |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
> > Check the google gson N files.
> >  |+-- zookeeper-backend-> OK
> >
> >  +-- kerby-dist
> >
> >  ||
> >
> >  |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
> > the google gson N files. need to add the slf4j N, add the netty's
> > NOTICE file
> >  |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j
> > N
> >
> >  +-- benchmark -> benchmarks, no N
> >  +-- kerby-provider
> >
> >   |
> >
> >   +- token-provider -> [nimbus-jose-jwt] -> check the nimbus-jose-jwt
> > N
> >
> >
> > AFAICT, there are not that many missing bits, but there is one more step
> > to complete : check the transitive depndencies.
> >
> > Running mvn dependency:tree on modules which have external dependencies
> > should give the required informations. Typically, on token-provider, here
> > is what it gives :
> >
> >
> > MacBook-Pro:token-provider elecharny$ mvn dependency:tree Java
> HotSpot(TM)
> > 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was
> > removed in 8.0 [INFO] Scanning for projects...
> > [INFO]
> >
> > [INFO]
> > 
> > [INFO] Building Token provider 1.0.0
> > [INFO]
> > 
> > [INFO]
> > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > token-provider --- [INFO] org.apache.kerby:token-provider:jar:1.0.0
> > [INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
> > [INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
> > [INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
> > [INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
>

Re: Questions about the release

2017-05-08 Thread Emmanuel Lecharny

As soon as I'll beback home !


Le lun. 8 mai 2017 à 09:27, Li, Jiajia  a écrit :

> I've added the slf4j N, mockito N, netty's NOTICE, hamcrest N,
> bouncycastle N(used by netty, but not included in it's N),
> Jline N(used by zookeeper, but not included in it's N)
> You can find out the NOTICE at NOTICE file, the licenses in LICENSE file
> and license/ folder.
>
> I also checked the following:
> >>> Check the google gson N files.
> Gson is released under the Apache 2.0 license.
>
> >>>check the nimbus-jose-jwt N
> The library source code is provided under the Apache 2.0 license.
>
> >>>nimbus-jose-jwt has itself some dependencies that requires some N
> (potentially, that has to be checked) :
> >>>jcip-annotations, json-smart and bcprov-jdk15on
> jcip-annotations, json-smart are under Apache 2.0 license, and I've added
> bouncycastle license
>
> And checked the transitive dependencies:
> commons-io: AL 2.0
> log4j: AL 2.0
> junit: AL 2.0
>
> @ Emmanuel, could you review the changes?
>
> Thanks
> Jiajia
>
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> To: kerby@directory.apache.org
> Subject: Questions about the release
>
> Hi guys,
>
>
> I have checked all the modules, and their dependencies. Here is the result
> :
>
>
> kerby-all -> test[junit, assertj-core] : OK, no N, test
>
>  |
>
>  +-- kerby-common -> [commons.io] : OK, no N, Apache
>  +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need to
> add the slf4j N
>  +-- kerby-kerb
>
>  ||
>
>  |+-- kerb-core -> OK
>
>  |+-- kerb-common -> [commons.io] : OK, no N, Apache
>  |+-- kerb-util -> test[mockito-core] : OK, no N, test
>  |+-- kerb-crypto -> OK
>  |+-- kerb-identity -> OK
>  |+-- kerb-identity-test -> test, no N
>  |+-- kerb-client -> test[mockito-core]: OK, no N, test
>  |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
>  |+-- kerb-kdc-test -> test, no N
>  |+-- integration-test -> test, no N
>  |+-- kerb-admin -> OK
>  |+-- kerb-admin-server -> OK
>  |+-- kerb-simplekdc -> OK
>  |+-- kerb-client-api-all -> OK
>  |+-- kerb-server-api-all -> OK
>  +-- kerby-kdc -> [netty-transport, netty-handler, netty-common,
> netty-codec, netty-buffer, slf4j-api] : Need to add the mockito mockito
> N, add the netty's NOTICE file
>
>  +-- kerby-tool
>
>  ||
>
>  |+-- client-tool -> OK
>  |+-- kdc-tool -> OK
>
>  +-- kerby-kdc-test  -> test, no N
>  +-- kerby-backend
>
>  ||
>
>  |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
>  |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
>  |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
> Check the google gson N files.
>  |+-- zookeeper-backend-> OK
>
>  +-- kerby-dist
>
>  ||
>
>  |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
> the google gson N files. need to add the slf4j N, add the netty's
> NOTICE file
>  |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j
> N
>
>  +-- benchmark -> benchmarks, no N
>  +-- kerby-provider
>
>   |
>
>   +- token-provider -> [nimbus-jose-jwt] -> check the nimbus-jose-jwt
> N
>
>
> AFAICT, there are not that many missing bits, but there is one more step
> to complete : check the transitive depndencies.
>
> Running mvn dependency:tree on modules which have external dependencies
> should give the required informations. Typically, on token-provider, here
> is what it gives :
>
>
> MacBook-Pro:token-provider elecharny$ mvn dependency:tree Java HotSpot(TM)
> 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was
> removed in 8.0 [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
> 
> [INFO] Building Token provider 1.0.0
> [INFO]
> 
> [INFO]
> [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> token-provider --- [INFO] org.apache.kerby:token-provider:jar:1.0.0
> [INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
> [INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
> [INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
> [INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
> [INFO] | \- org.slf4j:slf4j-api:jar:1.7.25:compile
> [INFO] +- com.nimbusds:nimbus-jose-jwt:jar:3.10:compile
> [INFO] |  +- net.jcip:jcip-annotations:jar:1.0:compile
> [INFO] |  +- net.minidev:json-smart:jar:1.3.1:compile
> [INFO] |  +- org.bouncycastle:bcprov-jdk15on:jar:1.52:compile
> [INFO] |  \- commons-io:commons-io:jar:2.4:compile
> [INFO] +- junit:junit:jar:4.12:test
> [INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
> [INFO] \- org.assertj:assertj-core:jar:2.6.0:test
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
>

Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

2017-05-08 Thread Christopher Lamb


Hi all

I hope this is the appropriate mailing list for this type of question. Or
would it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API
for a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When
the user logs on to his workstation he is authenticated by the FreeIPA KDC,
and  gets a TGT which is cached in the default credentials cache. When he
wishes to access services from the application server (which is a Service
Principal), the TGT in the credentials cache is used to get a Service
Ticket, which should also be cached in the credentials cache for future
use.

With a throwaway Python GSS-API client this worked perfectly. "klist" shows
both the TGT and the SGT in the credentials cache. But trying to do the
same thing with Java GSS-API I ran into problems. While the Client is able
to retrieve a Service Ticket, and thus login to the Service Principal, the
SGT is not cached. Thus every request to the Service Principal requires KDC
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am
experimenting with it, but so far without success despite much debugging
and scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an
existing Kerberos credential cache (as opposed to a KeyTab), and to use the
TGT ticket within, and to cache new service tickets? In this case the
existing credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I
find references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be
configuring?

Thanks

Chris

RE: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails

Re: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails

Re: Questions about the release

Re: Questions about the release

Re: MIT Kerberos compatibility

Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

Re: Questions about the release

Re: Questions about the release

Re: Questions about the release

Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

RE: MIT Kerberos compatibility

RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

RE: MIT Kerberos compatibility

Re: MIT Kerberos compatibility

RE: MIT Kerberos compatibility

Re: MIT Kerberos compatibility

Re: MIT Kerberos compatibility

Re: Questions about the release

Re: Questions about the release

Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.

23 matches

Site Navigation

Mail list logo

Footer information