RE: 1.1.0 release next week

[Zheng, Kai]

The plan is good to me. Nothing else I can think of to include. Thanks!

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, November 17, 2017 6:10 PM
To: kerby@directory.apache.org
Subject: 1.1.0 release next week

Hi all,

I'm planning to call a vote on the 1.1.0 release next week. Is there anything 
else anyone wants to include in the release?

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Needed changes to Kerby as a result of the introduction of the KdcClientRequest

[Zheng, Kai]

Hi Richard,

Thanks for the patch! It’s in good form. Could you fire a jira for the work and 
I will do a review in this weekend. Thanks.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Saturday, November 11, 2017 4:45 AM
To: Apache Directory Developers List 
Subject: Re: Needed changes to Kerby as a result of the introduction of the 
KdcClientRequest

Kai,

Having not created a GIT patch before, I selected all projects, right clicked 
to access the Team menu, selected Create Patch, and entered a file name. 
Attached you'll find the resulting file.

Regards,
Richard

On Fri, Nov 10, 2017 at 3:45 AM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
Sounds good, Gerard.

I’d like to see your patch and then have better idea. I understand the purpose 
and the proposed change.

Regards,
Kai

From: Gerard Gagliano [mailto:g...@apache.org<mailto:g...@apache.org>]
Sent: Friday, November 10, 2017 6:12 AM
To: d...@directory.apache.org<mailto:d...@directory.apache.org>
Subject: Needed changes to Kerby as a result of the introduction of the 
KdcClientRequest

We've been working to make the changes necessitated by the introduction of the 
KdcClientRequest class and the associated calling parameter changes.

Many data items needed by the authorization data backend code are not included 
in the KdcClientRequest class as defined in the 1.1.0-SNAPSHOT.  Modification 
of this class to include the necessary data items includes a reference to the 
KrbIdentity class.

This creates a circular dependency between the kerb-core project and the 
kerb-identity project.  The circular dependency can be resolved by moving 
KrbIdentity from kerb-identity to kerb-core.  Another suggestion is to more it 
to kerb-common.  And another suggestion is to remove KdcClientRequest from 
package ….kerb.type.kdc as all other classes in that package are ASN1 classes 
and this is not.

Moving the classes as follows resolves the circular dependency:
KdcClientRequest from kerb-core, and
KrbIdentity from kerb-identity
To kerb-common — package org.apache.kerby.kerberos.kerb.request

In addition, a dependency on kerb-common will be added to kerb-identity.

Without objection, we’ll move these classes.  If there is a better way than 
this, please suggest.

Thanks.




--
Richard M Feezel
rfee...@gmail.com<mailto:rfee...@gmail.com>

RE: 1.1.0 release?

[Zheng, Kai]

Sounds good and solid to have the 1.1.0 release! Thanks Colm.

Yes we could wait some bit for Gerard's changes.

Regards,
Kai

-Original Message-
From: Gerard Gagliano [mailto:g...@apache.org] 
Sent: Saturday, November 11, 2017 3:43 AM
To: kerby@directory.apache.org
Subject: Re: 1.1.0 release?

We would like to have the move and changes included for KdcClientRequest and 
KrbIdentity.  We will include a patch to the list hopefully by this evening.

> On Nov 10, 2017, at 8:30 AM, Colm O hEigeartaigh  wrote:
> 
> Hi all,
> 
> Are there any thoughts on a 1.1.0 release? The two new big features 
> (cross-realm + GSS support) are more or less ready. Is there anything 
> major left to be done for it?
> 
> Colm.
> 
> 
> --
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

RE: Transitive dependencies in the distributions

[Zheng, Kai]

Yes, I will go thru it today. Thanks! -kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Tuesday, November 07, 2017 5:46 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: Transitive dependencies in the distributions

Proposed patch here: https://issues.apache.org/jira/browse/DIRKRB-667
Colm.

On Mon, Nov 6, 2017 at 10:41 AM, Colm O hEigeartaigh 
mailto:cohei...@apache.org>> wrote:
Hi Kai,
No I think the fix is to include transitive dependencies, but to "exclude" any 
dependencies that are not required when listing the dependencies. I will take a 
look at it + submit a patch...
Colm.

On Mon, Nov 6, 2017 at 10:11 AM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
Good catch Colm!!

I couldn't recall the reall issue I was targeting at that time, but looks like 
the thinking is to list all the required modules explicitly. I guess the fix 
would be to add the missed deps?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Monday, November 06, 2017 5:54 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: Transitive dependencies in the distributions

Here it is:

commit c2fa7cc578c5c926691151bda6d464cad44c5376
Author: drankye mailto:kai.zh...@intel.com>>
Date:   Wed Jul 15 22:10:32 2015 +0800

Refined kdc-dist package

Colm.

On Mon, Nov 6, 2017 at 5:51 AM, Li, Jiajia 
mailto:jiajia...@intel.com>> wrote:

> Hi Colm,
>
> Which commit or patch lead to this issue?
>
> Thanks,
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Friday, November 3, 2017 7:06 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Transitive dependencies in the distributions
>
> Hi all,
>
> We are excluding transitive dependencies when copying the dependencies
> to the target/lib directory in the distributions. I'm wondering why?
> For example, I get an error due to the common jar not being present:
>
>   Caused by: java.lang.ClassNotFoundException:
> org.apache.kerby.kerberos.kerb.KrbException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Transitive dependencies in the distributions

[Zheng, Kai]

Good catch Colm!!

I couldn't recall the reall issue I was targeting at that time, but looks like 
the thinking is to list all the required modules explicitly. I guess the fix 
would be to add the missed deps?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, November 06, 2017 5:54 PM
To: kerby@directory.apache.org
Subject: Re: Transitive dependencies in the distributions

Here it is:

commit c2fa7cc578c5c926691151bda6d464cad44c5376
Author: drankye 
Date:   Wed Jul 15 22:10:32 2015 +0800

Refined kdc-dist package

Colm.

On Mon, Nov 6, 2017 at 5:51 AM, Li, Jiajia  wrote:

> Hi Colm,
>
> Which commit or patch lead to this issue?
>
> Thanks,
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, November 3, 2017 7:06 PM
> To: kerby@directory.apache.org
> Subject: Transitive dependencies in the distributions
>
> Hi all,
>
> We are excluding transitive dependencies when copying the dependencies 
> to the target/lib directory in the distributions. I'm wondering why? 
> For example, I get an error due to the common jar not being present:
>
>   Caused by: java.lang.ClassNotFoundException:
> org.apache.kerby.kerberos.kerb.KrbException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Kerby Update

[Zheng, Kai]

+ Directory.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Monday, October 23, 2017 10:38 AM
To: kerby@directory.apache.org
Subject: RE: Kerby Update

Cool!!

Thanks Jiajia & Frank for working on this this, cross realm trust support! I 
thought this makes Kerby a much further step, towards a decent and standalone 
Kerberos implementation.

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Monday, October 23, 2017 9:22 AM
To: kerby@directory.apache.org
Subject: Kerby Update

Hi all,

Recently we have implemented the cross-realm authentication support, KDC in one 
realm can authenticate users in a different realm, so it allows client from 
another realm to access the cluster. Cross-realm authentication is accomplished 
by sharing a secret key between the two realms. In both backends should have 
the krbtgt service principals for realms with same passwords, key version 
numbers, and encryption types. We have used this feature in Hadoop cluster, 
after establishing cross realm trust between two secure Hadoop clusters with 
their own realms, copying data between two secure clusters can work now. And 
this support also can be used to build trust relationship with MIT Kerberos KDC 
and we have tested compatibility.

Here is the document about setting up cross realm:
https://github.com/apache/directory-kerby/blob/trunk/docs/cross-realm.md

Thanks,
Jiajia

RE: Kerby Update

[Zheng, Kai]

Cool!!

Thanks Jiajia & Frank for working on this this, cross realm trust support! I 
thought this makes Kerby a much further step, towards a decent and standalone 
Kerberos implementation.

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Monday, October 23, 2017 9:22 AM
To: kerby@directory.apache.org
Subject: Kerby Update

Hi all,

Recently we have implemented the cross-realm authentication support, KDC in one 
realm can authenticate users in a different realm, so it allows client from 
another realm to access the cluster. Cross-realm authentication is accomplished 
by sharing a secret key between the two realms. In both backends should have 
the krbtgt service principals for realms with same passwords, key version 
numbers, and encryption types. We have used this feature in Hadoop cluster, 
after establishing cross realm trust between two secure Hadoop clusters with 
their own realms, copying data between two secure clusters can work now. And 
this support also can be used to build trust relationship with MIT Kerberos KDC 
and we have tested compatibility.

Here is the document about setting up cross realm:
https://github.com/apache/directory-kerby/blob/trunk/docs/cross-realm.md

Thanks,
Jiajia

RE: Anonymous PKINIT support

[Zheng, Kai]

Really sorry for the very late follow on discussions. These are indeed good 
questions, my answers to them would be all yes.

Quite some time ago we did want to make develop complete PKINIT and then start 
the work with the Anonymous support. That's why besides the Kerberos related 
codes, we also worked out lots of PKI related codes like cms, pki and etc., 
then stopped somewhere due to priority adjustment.

Anonymous PKINIT support is interesting because it can be used to establish an 
armor channel for the JWT token support without introducing too much overhead, 
like no client side certificate. But still need KDC side's public key and the 
validation chain.

Thanks for catching and raising the issue that client hasn't validated the 
KDC's reply checking its signature. If we claim the feature is done and can 
work, the security issue should be fixed. However, I'm not sure how easy it is 
to fix the issue, Jiajia might be able to provide some hints, looks like she is 
working on the cross-realm support, which is another big feature Kerby leaves 
to attack.

For the two cases of PKINIT (anonymous or client authenticated via x509 
certificate), I thought Kerby client should/could have separate APIs because 
they need different parameters and also rely on different configurations. So 
the KerbClient-KDC follow will be triggered in different two flows. 

I'm not sure if this helps some bit, if necessary, I can try to have bandwidth 
to provide my review/clarification when possible. It would be great to fix the 
gaps, delivering the Anonymous PKINIT feature.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, September 08, 2017 10:38 PM
To: kerby@directory.apache.org
Subject: Re: Anonymous PKINIT support

Now that I've finished the JWT access token work, it'd be nice to finish the 
Anonymous PKINIT side of things to get the Identity token part of it to work. 
Please review my questions below.

Colm.

On Tue, Jun 20, 2017 at 12:39 PM, Colm O hEigeartaigh 
wrote:

> Hi all,
>
> As per the recent email on JWT, I'd like to look at the outstanding 
> issues surrounding anonymous PKINIT support in Kerby.
>
> a) Last year I raised concerns about the KDC not signing the response:
>
> https://www.mail-archive.com/kerby@directory.apache.org/msg00808.html
>
> Currently, we don't use the private key at all in the KDC when it is 
> configured as part of KdcConfigKey.PKINIT_IDENTITY. The spec says that:
>
> https://tools.ietf.org/html/rfc6112
>
> "If the KDC's signature is missing in the KDC reply
>(the reply is anonymous), the client MUST reject the returned ticket
>if it cannot authenticate the KDC otherwise."
>
> I don't really see how the client can authenticate the KDC as things 
> stand, so I think we need to sign the KDC response and enforce a 
> signature on the client side.
>
> b) From the MIT page:
>
> "If you need to enable anonymity support for TGTs (for use as FAST 
> armor
> tickets) without enabling anonymous authentication to application 
> servers, you can set the variable restrict_anonymous_to_tgt to true in 
> the appropriate [realms] subsection of the KDC’s kdc.conf file."
>
> Is this supported by Kerby? I'm guessing not, but we should add 
> support for it.
>
> c) Is there a way to differentiate between anonymous + authenticated 
> PKINIT in the KDC configuration? What if you don't want to allow the 
> anonymous case?
>
> Colm.
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.1

[Zheng, Kai]

Oops, my bad. I just checked it the github site.
https://github.com/apache/directory-kerby

Thanks Colm, the update on the site looks pretty good and it makes total sense.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, September 13, 2017 7:33 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org; Li, Jiajia 
Subject: Re: [VOTE] - Release Apache Kerby 1.0.1

The release is already on the Kerby website:

http://directory.apache.org/kerby/news.html
http://directory.apache.org/kerby/downloads.html
Colm.

On Wed, Sep 13, 2017 at 12:27 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
Ok, I got it the reason. Colm you're much a senior Apache folk than me, I don't 
have question about the practice. I just thought we have it.

Maybe what we could do is, listing the release with the fixed bugs in Kerby 
project site, so some people could check it out. By the way, I'll suggest 
Hadoop will upgrade Kerby version to this release before or after the upcoming 
3.0 BETA 1, so that's why I asked.

Any contributor would love to take this? Thanks!

-kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Wednesday, September 13, 2017 7:13 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Cc: Li, Jiajia mailto:jiajia...@intel.com>>
Subject: Re: [VOTE] - Release Apache Kerby 1.0.1

I didn't write an official "announcement" email, I didn't bother as it is only 
a minor release. If you'd like I could send one out though?

Colm.

On Wed, Sep 13, 2017 at 12:09 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

> Thanks Colm and Jiajia for making it happen.
>
> Where we can get notified by the announcement? Before I can receive
> such announcement messages, but now I don't, not sure what's wrong.
>
> -kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Wednesday, September 13, 2017 4:41 PM
> To: Li, Jiajia mailto:jiajia...@intel.com>>
> Cc: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: [VOTE] - Release Apache Kerby 1.0.1
>
> Yes it is released, and available in the central maven repository and
> in the usual Apache "dist".
>
> Colm.
>
> On Wed, Sep 13, 2017 at 9:10 AM, Li, Jiajia 
> mailto:jiajia...@intel.com>> wrote:
>
> > Hi Colm,
> > Has the 1.0.1 released? Could I use the 1.0.1 release version now?
> >
> > Thanks,
> > Jiajia
> >
> > -Original Message-
> > From: Colm O hEigeartaigh 
> > [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> > Sent: Monday, September 4, 2017 6:48 PM
> > To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> > Subject: Re: [VOTE] - Release Apache Kerby 1.0.1
> >
> > Thanks to everyone who voted. We have 6 binding +1 votes, and one
> > non-binding +1 vote, and so this vote passes - I'll do the release.
> >
> > Colm.
> >
> > On Mon, Sep 4, 2017 at 7:49 AM, Emmanuel Lécharny
> > mailto:elecha...@gmail.com>>
> > wrote:
> >
> > > Finaly whipped it :-)
> > >
> > >
> > > Built from tag and package, N&L checked : all is good
> > >
> > >
> > > +1 !
> > >
> > >
> > > Le 30/08/2017 à 12:30, Colm O hEigeartaigh a écrit :
> > > > This is a vote to release Apache Kerby 1.0.1.
> > > >
> > > > Issues fixed:
> > > >
> > > > https://issues.apache.org/jira/projects/DIRKRB/versions/12340574
> > > >
> > > > Git tag:
> > > >
> > > > https://github.com/apache/directory-kerby/tree/kerby-all-1.0.1
> > > >
> > > > Artifacts:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapachedirectory-1146/
> > > >
> > > > In particular, the source artifacts:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapachedirectory-1146/org/apache/kerby/kerby-all/1.0.1/
> > > >
> > > > +1 from me.
> > > >
> > > > Colm.
> > > >
> > > >
> > >
> > > --
> > > Emmanuel Lecharny
> > >
> > > Symas.com
> > > directory.apache.org<http://directory.apache.org>
> > >
> > >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.1

[Zheng, Kai]

Ok, I got it the reason. Colm you're much a senior Apache folk than me, I don't 
have question about the practice. I just thought we have it.

Maybe what we could do is, listing the release with the fixed bugs in Kerby 
project site, so some people could check it out. By the way, I'll suggest 
Hadoop will upgrade Kerby version to this release before or after the upcoming 
3.0 BETA 1, so that's why I asked.

Any contributor would love to take this? Thanks!

-kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, September 13, 2017 7:13 PM
To: kerby@directory.apache.org
Cc: Li, Jiajia 
Subject: Re: [VOTE] - Release Apache Kerby 1.0.1

I didn't write an official "announcement" email, I didn't bother as it is only 
a minor release. If you'd like I could send one out though?

Colm.

On Wed, Sep 13, 2017 at 12:09 PM, Zheng, Kai  wrote:

> Thanks Colm and Jiajia for making it happen.
>
> Where we can get notified by the announcement? Before I can receive 
> such announcement messages, but now I don't, not sure what's wrong.
>
> -kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, September 13, 2017 4:41 PM
> To: Li, Jiajia 
> Cc: kerby@directory.apache.org
> Subject: Re: [VOTE] - Release Apache Kerby 1.0.1
>
> Yes it is released, and available in the central maven repository and 
> in the usual Apache "dist".
>
> Colm.
>
> On Wed, Sep 13, 2017 at 9:10 AM, Li, Jiajia  wrote:
>
> > Hi Colm,
> > Has the 1.0.1 released? Could I use the 1.0.1 release version now?
> >
> > Thanks,
> > Jiajia
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Monday, September 4, 2017 6:48 PM
> > To: kerby@directory.apache.org
> > Subject: Re: [VOTE] - Release Apache Kerby 1.0.1
> >
> > Thanks to everyone who voted. We have 6 binding +1 votes, and one 
> > non-binding +1 vote, and so this vote passes - I'll do the release.
> >
> > Colm.
> >
> > On Mon, Sep 4, 2017 at 7:49 AM, Emmanuel Lécharny 
> > 
> > wrote:
> >
> > > Finaly whipped it :-)
> > >
> > >
> > > Built from tag and package, N&L checked : all is good
> > >
> > >
> > > +1 !
> > >
> > >
> > > Le 30/08/2017 à 12:30, Colm O hEigeartaigh a écrit :
> > > > This is a vote to release Apache Kerby 1.0.1.
> > > >
> > > > Issues fixed:
> > > >
> > > > https://issues.apache.org/jira/projects/DIRKRB/versions/12340574
> > > >
> > > > Git tag:
> > > >
> > > > https://github.com/apache/directory-kerby/tree/kerby-all-1.0.1
> > > >
> > > > Artifacts:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapachedirectory-1146/
> > > >
> > > > In particular, the source artifacts:
> > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapachedirectory-1146/org/apache/kerby/kerby-all/1.0.1/
> > > >
> > > > +1 from me.
> > > >
> > > > Colm.
> > > >
> > > >
> > >
> > > --
> > > Emmanuel Lecharny
> > >
> > > Symas.com
> > > directory.apache.org
> > >
> > >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.1

[Zheng, Kai]

Thanks Colm and Jiajia for making it happen.

Where we can get notified by the announcement? Before I can receive such 
announcement messages, but now I don't, not sure what's wrong.

-kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, September 13, 2017 4:41 PM
To: Li, Jiajia 
Cc: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.1

Yes it is released, and available in the central maven repository and in the 
usual Apache "dist".

Colm.

On Wed, Sep 13, 2017 at 9:10 AM, Li, Jiajia  wrote:

> Hi Colm,
> Has the 1.0.1 released? Could I use the 1.0.1 release version now?
>
> Thanks,
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, September 4, 2017 6:48 PM
> To: kerby@directory.apache.org
> Subject: Re: [VOTE] - Release Apache Kerby 1.0.1
>
> Thanks to everyone who voted. We have 6 binding +1 votes, and one 
> non-binding +1 vote, and so this vote passes - I'll do the release.
>
> Colm.
>
> On Mon, Sep 4, 2017 at 7:49 AM, Emmanuel Lécharny 
> 
> wrote:
>
> > Finaly whipped it :-)
> >
> >
> > Built from tag and package, N&L checked : all is good
> >
> >
> > +1 !
> >
> >
> > Le 30/08/2017 à 12:30, Colm O hEigeartaigh a écrit :
> > > This is a vote to release Apache Kerby 1.0.1.
> > >
> > > Issues fixed:
> > >
> > > https://issues.apache.org/jira/projects/DIRKRB/versions/12340574
> > >
> > > Git tag:
> > >
> > > https://github.com/apache/directory-kerby/tree/kerby-all-1.0.1
> > >
> > > Artifacts:
> > >
> > > https://repository.apache.org/content/repositories/
> > orgapachedirectory-1146/
> > >
> > > In particular, the source artifacts:
> > >
> > > https://repository.apache.org/content/repositories/
> > orgapachedirectory-1146/org/apache/kerby/kerby-all/1.0.1/
> > >
> > > +1 from me.
> > >
> > > Colm.
> > >
> > >
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Anonymous PKINIT support

[Zheng, Kai]

Thanks Colm for the sharing and telling the story!!

The blog looks pretty informative. I thought we should list or mention it 
somewhere in our Directory/Kerby projects.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, September 11, 2017 7:30 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: Anonymous PKINIT support

OK thanks! I wrote up the "access token" case as part of a blog post in the 
context of a kerberized JAX-RS web service request using Apache CXF:

http://coheigea.blogspot.ie/2017/09/integrating-json-web-tokens-with.html

Colm.

On Sat, Sep 9, 2017 at 5:50 AM, Zheng, Kai  wrote:

> Thanks Colm for the take. I'll try to bring up the context in my mind 
> and give you some comments later.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, September 08, 2017 10:38 PM
> To: kerby@directory.apache.org
> Subject: Re: Anonymous PKINIT support
>
> Now that I've finished the JWT access token work, it'd be nice to 
> finish the Anonymous PKINIT side of things to get the Identity token 
> part of it to work. Please review my questions below.
>
> Colm.
>
> On Tue, Jun 20, 2017 at 12:39 PM, Colm O hEigeartaigh 
>  >
> wrote:
>
> > Hi all,
> >
> > As per the recent email on JWT, I'd like to look at the outstanding 
> > issues surrounding anonymous PKINIT support in Kerby.
> >
> > a) Last year I raised concerns about the KDC not signing the response:
> >
> > https://www.mail-archive.com/kerby@directory.apache.org/msg00808.htm
> > l
> >
> > Currently, we don't use the private key at all in the KDC when it is 
> > configured as part of KdcConfigKey.PKINIT_IDENTITY. The spec says that:
> >
> > https://tools.ietf.org/html/rfc6112
> >
> > "If the KDC's signature is missing in the KDC reply
> >(the reply is anonymous), the client MUST reject the returned ticket
> >if it cannot authenticate the KDC otherwise."
> >
> > I don't really see how the client can authenticate the KDC as things 
> > stand, so I think we need to sign the KDC response and enforce a 
> > signature on the client side.
> >
> > b) From the MIT page:
> >
> > "If you need to enable anonymity support for TGTs (for use as FAST 
> > armor
> > tickets) without enabling anonymous authentication to application 
> > servers, you can set the variable restrict_anonymous_to_tgt to true 
> > in the appropriate [realms] subsection of the KDC’s kdc.conf file."
> >
> > Is this supported by Kerby? I'm guessing not, but we should add 
> > support for it.
> >
> > c) Is there a way to differentiate between anonymous + authenticated 
> > PKINIT in the KDC configuration? What if you don't want to allow the 
> > anonymous case?
> >
> > Colm.
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [DISCUSS] - gitbox migration

[Zheng, Kai]

Sounds good to me. The advantage looks obvious. How to do that? A infra jira?

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, September 13, 2017 1:02 PM
To: kerby@directory.apache.org
Subject: Re: [DISCUSS] - gitbox migration



Le 12/09/2017 à 14:01, Colm O hEigeartaigh a écrit :
> Hi all,
>
> Other git-based projects at Apache, such as the new git repo for the 
> Apache Directory LDAP API or Apache CXF, have moved to use 
> gitbox.apache.org. The main advantage is that the source is 
> automatically synced with github, and hence we can push commits 
> directly to github, thus making merging PRs a lot easier.
>
> IMO we should also migrate...any thoughts?

To me, it's a no brainer.
My 2 cts :-)

--
Emmanuel Lecharny

Symas.com
directory.apache.org

RE: Anonymous PKINIT support

[Zheng, Kai]

Thanks Colm for the take. I'll try to bring up the context in my mind and give 
you some comments later.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, September 08, 2017 10:38 PM
To: kerby@directory.apache.org
Subject: Re: Anonymous PKINIT support

Now that I've finished the JWT access token work, it'd be nice to finish the 
Anonymous PKINIT side of things to get the Identity token part of it to work. 
Please review my questions below.

Colm.

On Tue, Jun 20, 2017 at 12:39 PM, Colm O hEigeartaigh 
wrote:

> Hi all,
>
> As per the recent email on JWT, I'd like to look at the outstanding 
> issues surrounding anonymous PKINIT support in Kerby.
>
> a) Last year I raised concerns about the KDC not signing the response:
>
> https://www.mail-archive.com/kerby@directory.apache.org/msg00808.html
>
> Currently, we don't use the private key at all in the KDC when it is 
> configured as part of KdcConfigKey.PKINIT_IDENTITY. The spec says that:
>
> https://tools.ietf.org/html/rfc6112
>
> "If the KDC's signature is missing in the KDC reply
>(the reply is anonymous), the client MUST reject the returned ticket
>if it cannot authenticate the KDC otherwise."
>
> I don't really see how the client can authenticate the KDC as things 
> stand, so I think we need to sign the KDC response and enforce a 
> signature on the client side.
>
> b) From the MIT page:
>
> "If you need to enable anonymity support for TGTs (for use as FAST 
> armor
> tickets) without enabling anonymous authentication to application 
> servers, you can set the variable restrict_anonymous_to_tgt to true in 
> the appropriate [realms] subsection of the KDC’s kdc.conf file."
>
> Is this supported by Kerby? I'm guessing not, but we should add 
> support for it.
>
> c) Is there a way to differentiate between anonymous + authenticated 
> PKINIT in the KDC configuration? What if you don't want to allow the 
> anonymous case?
>
> Colm.
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.1

[Zheng, Kai]

Thanks Colm for this!

The fixed issues look great to have and the release artifacts are good.

+1 from me.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, August 30, 2017 6:31 PM
To: kerby@directory.apache.org; Apache Directory Developers List 

Subject: [VOTE] - Release Apache Kerby 1.0.1

This is a vote to release Apache Kerby 1.0.1.

Issues fixed:

https://issues.apache.org/jira/projects/DIRKRB/versions/12340574

Git tag:

https://github.com/apache/directory-kerby/tree/kerby-all-1.0.1

Artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1146/

In particular, the source artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1146/org/apache/kerby/kerby-all/1.0.1/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Kerby 1.0.1 release

[Zheng, Kai]

IMO we should go for the 1.0.1 release since the previous 1.0.0 major release 
had passed some time. The minor release did fix some important bugs and we 
should suggest users use this minor release instead.

Are there any critical issues we want to target for the minor release?

Kerby users/committers, any comment? Thanks!

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Friday, August 18, 2017 11:32 AM
To: kerby@directory.apache.org
Subject: Kerby new minor release

Hi all,

After Kerby 1.0.0 released, 12 issues were resolved, including following bug 
fix and improvement:
Fix the issue not compatible with MIT Kerberos: 
DIRKRB-614, 
DIRKRB-631;
Fix the network related issue: 
DIRKRB-629;
And with some improvements in token preauth and kinit;

I suggest we can make the new minor release. How do you think about it?

Thanks,
Jiajia

RE: GSSAPI branch

[Zheng, Kai]

Merging it into trunk is fine to me. I suggest the contributor Wei answer your 
questions.

Do we want to do an important release (like 1.1.0) to contain the big portion 
of codes? It looks big for the minor 1.0.1 release. I guess we may need longer 
time to make it mature.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, July 24, 2017 4:56 PM
To: kerby@directory.apache.org
Cc: Zhou, Wei 
Subject: Re: GSSAPI branch

Apologies, I made a mistake when merging on Friday, actually I ended up merging 
the gssapi branch to trunk, not gssapi-rebase as I thought. So the question is, 
what is missing for the current gssapi code on trunk before we can release it?

Colm.

On Mon, Jul 24, 2017 at 9:19 AM, Colm O hEigeartaigh 
wrote:

> Just to clarify, the "gssapi-rebase" branch is the current trunk 
> branch with the fixes that were originally ported to "gssapi" applied. 
> So the "gssapi" branch can be ignored at this point. Once we are happy 
> with the code then we can merge gssapi-rebase to trunk. What is the "gss-v2" 
> branch?
>
> Colm.
>
> On Fri, Jul 21, 2017 at 10:03 PM, Zheng, Kai  wrote:
>
>> Thanks Colm for the moving on.
>>
>> I did remember we didn't attempt to merge the work into trunk is 
>> because it lacked necessary unit tests but I guess Wei had already 
>> implemented some tests? Just checked the codes just merged in, I didn't find 
>> them.
>>
>> @Wei could you help do a check? There're two branches related. It 
>> would be great if you could make sure all your gssapi related codes 
>> and tests were made in the trunk, so we can safely clean up.
>> gss-v2;
>> gssapi.
>>
>> Thanks Wei for the big contribution and look forward to making it work.
>>
>> Regards,
>> Kai
>>
>> -Original Message-
>> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
>> Sent: Friday, July 21, 2017 11:06 PM
>> To: kerby@directory.apache.org
>> Subject: GSSAPI branch
>>
>> I've created a new branch called "gssapi-rebase". I tried to rebase 
>> the gssapi branch with the trunk branch but hit a ton of merge 
>> conflicts. The gssapi-rebase branch is the current trunk branch with 
>> the original GSSAPI patches that were submitted, as well as a few other 
>> fixes.
>>
>> If there are no objections, I'll delete the gssapi branch
>>
>> Colm.
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: GSSAPI branch

[Zheng, Kai]

Thanks Colm for the moving on. 

I did remember we didn't attempt to merge the work into trunk is because it 
lacked necessary unit tests but I guess Wei had already implemented some tests? 
Just checked the codes just merged in, I didn't find them. 

@Wei could you help do a check? There're two branches related. It would be 
great if you could make sure all your gssapi related codes and tests were made 
in the trunk, so we can safely clean up.
gss-v2;
gssapi.

Thanks Wei for the big contribution and look forward to making it work.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, July 21, 2017 11:06 PM
To: kerby@directory.apache.org
Subject: GSSAPI branch

I've created a new branch called "gssapi-rebase". I tried to rebase the gssapi 
branch with the trunk branch but hit a ton of merge conflicts. The 
gssapi-rebase branch is the current trunk branch with the original GSSAPI 
patches that were submitted, as well as a few other fixes.

If there are no objections, I'll delete the gssapi branch

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Kerby SgtTicket to GSS token?

[Zheng, Kai]

It needs kerby own GSSAPI implementation to accept kerby SgtTicket and send it 
to the target service. JRE doesn't provide any API allowing to hook logics like 
this. Not sure if you could make it if you would try the gssapi branch. 

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, July 11, 2017 7:11 PM
To: kerby@directory.apache.org
Subject: Kerby SgtTicket to GSS token?

Hi all,

Given a Kerby SgtTicket, is it possible to translate this into a GSS token 
somehow? Let's say I want to invoke on a service which uses GSS to validate the 
ticket, but obtain the ticket in the first place using Kerby's APIs.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: MIT Kerberos compatibility

[Zheng, Kai]

This sounds great. IIRC, you have another TCP/UDP network related issue to be 
fixed yet? Maybe we fix it as well to justify a new minor release.

Regards,
Kai

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

Yes, it works perfectly, thanks Jiajia for the fix! I'll resolve the JIRA.

Colm.

On Mon, Jun 19, 2017 at 6:09 AM, Li, Jiajia  wrote:

> Hi Colm,
> Thanks for providing the way to reproduce the error, and I have the fix in
> trunk code, can you take some time to check it?
>
> Commit log:
> commit 106299efb7aa3001da89ae821eb43285c544bab7
> Author: plusplusjiajia 
> Date:   Mon Jun 19 13:07:04 2017 +0800
>
> Fix DIRKRB-629:ICMP Port Unreachable error message with GSS + default
> transport.
>
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, May 8, 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
>

RE: [Kerby] TGS req failing with "Unexpected item context"

[Zheng, Kai]

Thank you Jiajia for your taking time to fix this long hanging issue. The fix 
looks great!

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, June 14, 2017 10:42 AM
To: kerby@directory.apache.org
Subject: RE: [Kerby] TGS req failing with "Unexpected item context"

Hi all,
I have some fix for this issue, could anyone help me to check it using your 
test env? 

Commit log is:
commit a6224d2cf60e8e18ba5e307f1a4a2bc4c01a55b4
Author: plusplusjiajia 
Date:   Wed Jun 14 10:43:46 2017 +0800

Fix DIRKRB-614 and DIRKRB-631.

Thanks
Jiajia

-Original Message-
From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl]
Sent: Thursday, June 8, 2017 8:10 PM
To: kerby@directory.apache.org
Subject: Re: [Kerby] TGS req failing with "Unexpected item context"

Hi Kai,

See, my original logs from both the python client and the KDC at (this link is 
also present in DIRKRB-631):

http://mail-archives.apache.org/mod_mbox/directory-kerby/201705.mbox/browser

Here, the logs of the python client coincide with Pratyush's report in the 
current thread. The logs of the KDC coincide with the old
DIRKKRB-614 issue.

I would say all reports are related to the same error, Kerby not being able the 
decode the FAST OTP requests of MIT Kerberos 1.11+. Also, all are related to a 
TGS request based on an existing TGT.

Cheers,Marc


Op 06-06-17 om 21:07 schreef Marc de Lignie:
> Dear all,
>
> My bad, it seems I made a separate issue for this, which might add 
> more details to DIRKRB-614 and might help you in finding the decode
> error:
>
> https://issues.apache.org/jira/browse/DIRKRB-631
>
> The workaround I mentioned is there, in the comments.
>
> Cheers,   Marc
>
>
> Op 06-06-17 om 21:02 schreef Marc de Lignie:
>> Pratjush,
>>
>> I just posted a temporary workaround as a comment below:
>>
>> https://issues.apache.org/jira/browse/DIRKRB-614
>>
>> Cheers,Marc
>>
>>
>> Kai wrote:
>>
>> It seems so and we need to fix it. However, I don't see any obvious 
>> cause for it. Hope we can get to this sooner (should be next week) 
>> after some deadline is caught. Sorry for the late.
>>
>> Regards,
>> Kai
>>
>> -Original Message-
>> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
>> Sent: Monday, June 05, 2017 12:04 AM
>> To: kerby@directory.apache.org
>> Subject: Re: [Kerby] TGS req failing with "Unexpected item context"
>>
>> Looks like you're running into this known issue:
>>
>> https://issues.apache.org/jira/browse/DIRKRB-614
>>
>> Colm.
>>
>> On Sat, Jun 3, 2017 at 8:09 PM, pratyush parimal 
>> >> wrote:
>>
>>> Hi everyone,
>>>
>>> I'm writing a simple Java program that stands up a KDC using the 
>>> SimpleKdcServer class, and I'm trying to use it for AS & TGS 
>>> operations. Relevant code is below:
>>>
>>> kdc = new SimpleKdcServer(); 
>>> kdc.setKdcHost("kdc.example.com");
>>> kdc.setKdcPort(60088);
>>> kdc.setKdcRealm("EXAMPLE.COM");
>>>
>>> kdc.setAllowUdp(false);
>>> kdc.setWorkDir(keytabFile.getParentFile());
>>>
>>> kdc.init();
>>>
>>> kdc.createPrincipal("u...@example.com", "u1pwd"); 
>>> kdc.createPrincipal("myservice/kdc.example@example.com",
>>> "myservicepwd");
>>>
>>> kdc.start();
>>>
>>> I use kinit to fetch the TGT for my principal "u1" and that's 
>>> successful.
>>> However, the subsequent TGS req from my client program fails with 
>>> the
>>> error:
>>>
>>> GSSAPI continuation error: Unknown code krcM 137
>>>
>>> . I debugged through the source code for Kerby and saw that the full 
>>> exception was not getting thrown because of a (e instanceof
>>> KdcRecoverableException) check. When I print the stacktrace via a 
>>> debugger, I see the following (apologies for the huge stack trace):
>>>
>>> [pool-1-thread-1] INFO
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest - Found 
>>> fast padata and starting to process it.
>>> org.apache.kerby.kerberos.kerb.KrbException: Decoding failed at
>>> org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:85)
>>> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:70)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.kdcFindFast
>>> (
>>> KdcRequest.java:213)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.
>>> KdcRequest.process(KdcRequest.java:170)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.KdcHandler.
>>> handleMessage(KdcHandler.java:116)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.
>>> handleMessage(DefaultKdcHandler.java:67)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(
>>> DefaultKdcHandler.java:52)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>>> ThreadPoolExecutor.java:1145)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>> ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:745)
>>> Caused by: java.io.IOException: Unexpected item context [0] 
>>> [tag=0xA0, off=0, len=3+198], expecting 0x30 at 
>>> org.apache.kerby.asn1

RE: [Kerby] TGS req failing with "Unexpected item context"

[Zheng, Kai]

Hi Marc,

Thanks for your report and digging. I don't quite follow and am not sure it's 
pointing to the same issue? In your case does Kerby KDC report the same 
exception?

Regards,
Kai

-Original Message-
From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl] 
Sent: Wednesday, June 07, 2017 3:02 AM
To: kerby@directory.apache.org
Subject: RE: [Kerby] TGS req failing with "Unexpected item context"

Pratjush,

I just posted a temporary workaround as a comment below:

https://issues.apache.org/jira/browse/DIRKRB-614

Cheers,Marc


Kai wrote:

It seems so and we need to fix it. However, I don't see any obvious cause for 
it. Hope we can get to this sooner (should be next week) after some deadline is 
caught. Sorry for the late.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, June 05, 2017 12:04 AM
To: kerby@directory.apache.org
Subject: Re: [Kerby] TGS req failing with "Unexpected item context"

Looks like you're running into this known issue:

https://issues.apache.org/jira/browse/DIRKRB-614

Colm.

On Sat, Jun 3, 2017 at 8:09 PM, pratyush parimal  wrote:

> Hi everyone,
>
> I'm writing a simple Java program that stands up a KDC using the 
> SimpleKdcServer class, and I'm trying to use it for AS & TGS 
> operations. Relevant code is below:
>
> kdc = new SimpleKdcServer();
> kdc.setKdcHost("kdc.example.com");
> kdc.setKdcPort(60088);
> kdc.setKdcRealm("EXAMPLE.COM");
>
> kdc.setAllowUdp(false);
> kdc.setWorkDir(keytabFile.getParentFile());
>
> kdc.init();
>
> kdc.createPrincipal("u...@example.com", "u1pwd"); 
> kdc.createPrincipal("myservice/kdc.example@example.com",
> "myservicepwd");
>
> kdc.start();
>
> I use kinit to fetch the TGT for my principal "u1" and that's successful.
> However, the subsequent TGS req from my client program fails with the
> error:
>
> GSSAPI continuation error: Unknown code krcM 137
>
> . I debugged through the source code for Kerby and saw that the full 
> exception was not getting thrown because of a (e instanceof
> KdcRecoverableException) check. When I print the stacktrace via a 
> debugger, I see the following (apologies for the huge stack trace):
>
> [pool-1-thread-1] INFO
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest - Found fast 
> padata and starting to process it.
> org.apache.kerby.kerberos.kerb.KrbException: Decoding failed at
> org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:85)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:70)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.kdcFindFast(
> KdcRequest.java:213)
> at
> org.apache.kerby.kerberos.kerb.server.request.
> KdcRequest.process(KdcRequest.java:170)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.
> handleMessage(KdcHandler.java:116)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.
> handleMessage(DefaultKdcHandler.java:67)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(
> DefaultKdcHandler.java:52)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Unexpected item context [0] [tag=0xA0, 
> off=0, len=3+198], expecting 0x30 at 
> org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:219)
> at org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:207)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:83)
> ... 9 more
> org.apache.kerby.kerberos.kerb.KrbException: Decoding failed at
> org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:85)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:70)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.kdcFindFast(
> KdcRequest.java:213)
> at
> org.apache.kerby.kerberos.kerb.server.request.
> KdcRequest.process(KdcRequest.java:170)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.
> handleMessage(KdcHandler.java:116)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.
> handleMessage(DefaultKdcHandler.java:67)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(
> DefaultKdcHandler.java:52)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Unexpected item context [0] [tag=0xA0, 
> off=0, len=3+198], expecting 0x30 at 
> org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:219)
> at org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:207)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:83)
> ... 9 more
>
> The client program (and also kinit) were using the krb5.conf that was 
> auto-gener

RE: [Kerby] TGS req failing with "Unexpected item context"

[Zheng, Kai]

It seems so and we need to fix it. However, I don't see any obvious cause for 
it. Hope we can get to this sooner (should be next week) after some deadline is 
caught. Sorry for the late.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, June 05, 2017 12:04 AM
To: kerby@directory.apache.org
Subject: Re: [Kerby] TGS req failing with "Unexpected item context"

Looks like you're running into this known issue:

https://issues.apache.org/jira/browse/DIRKRB-614

Colm.

On Sat, Jun 3, 2017 at 8:09 PM, pratyush parimal  wrote:

> Hi everyone,
>
> I'm writing a simple Java program that stands up a KDC using the 
> SimpleKdcServer class, and I'm trying to use it for AS & TGS 
> operations. Relevant code is below:
>
> kdc = new SimpleKdcServer();
> kdc.setKdcHost("kdc.example.com");
> kdc.setKdcPort(60088);
> kdc.setKdcRealm("EXAMPLE.COM");
>
> kdc.setAllowUdp(false);
> kdc.setWorkDir(keytabFile.getParentFile());
>
> kdc.init();
>
> kdc.createPrincipal("u...@example.com", "u1pwd"); 
> kdc.createPrincipal("myservice/kdc.example@example.com",
> "myservicepwd");
>
> kdc.start();
>
> I use kinit to fetch the TGT for my principal "u1" and that's successful.
> However, the subsequent TGS req from my client program fails with the
> error:
>
> GSSAPI continuation error: Unknown code krcM 137
>
> . I debugged through the source code for Kerby and saw that the full 
> exception was not getting thrown because of a (e instanceof
> KdcRecoverableException) check. When I print the stacktrace via a 
> debugger, I see the following (apologies for the huge stack trace):
>
> [pool-1-thread-1] INFO
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest - Found fast 
> padata and starting to process it.
> org.apache.kerby.kerberos.kerb.KrbException: Decoding failed at 
> org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:85)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:70)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.kdcFindFast(
> KdcRequest.java:213)
> at
> org.apache.kerby.kerberos.kerb.server.request.
> KdcRequest.process(KdcRequest.java:170)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.
> handleMessage(KdcHandler.java:116)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.
> handleMessage(DefaultKdcHandler.java:67)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(
> DefaultKdcHandler.java:52)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Unexpected item context [0] [tag=0xA0, 
> off=0, len=3+198], expecting 0x30 at 
> org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:219)
> at org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:207)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:83)
> ... 9 more
> org.apache.kerby.kerberos.kerb.KrbException: Decoding failed at 
> org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:85)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:70)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.kdcFindFast(
> KdcRequest.java:213)
> at
> org.apache.kerby.kerberos.kerb.server.request.
> KdcRequest.process(KdcRequest.java:170)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.
> handleMessage(KdcHandler.java:116)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.
> handleMessage(DefaultKdcHandler.java:67)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(
> DefaultKdcHandler.java:52)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Unexpected item context [0] [tag=0xA0, 
> off=0, len=3+198], expecting 0x30 at 
> org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:219)
> at org.apache.kerby.asn1.type.Asn1Encodeable.decode(
> Asn1Encodeable.java:207)
> at org.apache.kerby.kerberos.kerb.KrbCodec.decode(KrbCodec.java:83)
> ... 9 more
>
> The client program (and also kinit) were using the krb5.conf that was 
> auto-generated by the SimpleKdcServer in the workdir, and looked like 
> the following (I just replaced localhost with the FQDN of my machine):
>
> [libdefaults]
> kdc_realm = EXAMPLE.COM
> default_realm = EXAMPLE.COM
> udp_preference_limit = 1
> kdc_tcp_port = 60088
> #_KDC_UDP_PORT_
>
> [realms]
> EXAMPLE.COM = {
> kdc = kdc.example.com:60088
> }
>
> I had also enabled KRB5_TRACE on my client program that was making the 
> TGS req, and it shows the following:
>
>
> [1588796] 1496515969.488037: ccselect can't find appropr

Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Sent from iPhone

> 在 2017年5月18日，上午1:33，Colm O hEigeartaigh  写道：
> 
> I think Kerby is a promising project, but I don't think it has the
> community yet to justify being a TLP. Hopefully as more Big Data projects
> adopt it for testing it will continue to grow. Apache WSS4J and CXF have
> switched to use Kerby 1.0.0 for integeration testing. I will shortly submit
> a patch to Apache Ranger to use it as well, as there are no kerberos
> integration tests done there.
> 
> Colm.
> 
> On Wed, May 17, 2017 at 3:32 PM, Emmanuel Lécharny 
> wrote:
> 
>> 
>> 
>>> Le 17/05/2017 à 15:06, Zheng, Kai a écrit :
>>> Good ask. Maybe we could address questions like such:
>>> 1. How many issues we fixed since RC2 release, any features we've added?
>>> 2. A summary about Kerby and high level functionalities list?
>>> 3. Some links to the release artifacts and project.
>>> 
>>> Not sure if any best practice here.
>> 
>> The best practice is to send an announcement on annou...@apache.org, but
>> you already know that.
>> 
>> You may want to be a bit broader : please contact pr...@apache.org
>> (Sally Khudairi) if you want some more PR, they would be pleased to help
>> you drafting something that will be pushed to other channels.
>> 
>> 
>> That being said, you should also start thinking about moving Kerby to a
>> TLP, now that 1.0 is out. Please consider doing so while discussing with
>> press@a.o, so that both moves are done at the same time, in order to
>> have more spotlights on the project.
>> 
>> --
>> Emmanuel Lecharny
>> 
>> Symas.com
>> directory.apache.org
>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

>> I think Kerby is a promising project, but I don't think it has the community 
>> yet to justify being a TLP.
Yeah, Kerberos isn't the cool thing that many developers are eager to work on. 
There are many reasons. So we probably shouldn't expect a large community for 
this, it may never happen.

On the other hand, here is the community, as the Apache Directory community. If 
we have a TLP, we can duplicate the PMCs and committers. Kerby itself does have 
already diverse committers.

My two cents. The question is, would a TLP make Kerby and Directory more 
healthy, or make us more happy, or make new contributors more easy? Simpler, if 
a TLP can help build and attract a better community for Kerby, we probably 
should go.

Thanks Colm for the work to use Kerby in other ASF projects. It does help. I 
thought we folks here could be able to build a better ecosystem in the security 
domain for Apache world, we have LDAP and Kerberos, the security basics, the 
very good base. IMO, we should have quite a few TLP projects around the two 
basics, instead of ONE monster of so many children projects all here together, 
looking at the Directory hope page. If I'm a developer and want to contribute 
to Kerby, I would be frustrated to figure out the right ML, the right REPO and 
the right relationship/deps with other components. 

Kerby should have the potential, Directory and big data projects can use it. 
The question is, will a TLP make Kerby next solid step?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, May 18, 2017 12:34 AM
To: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

I think Kerby is a promising project, but I don't think it has the community 
yet to justify being a TLP. Hopefully as more Big Data projects adopt it for 
testing it will continue to grow. Apache WSS4J and CXF have switched to use 
Kerby 1.0.0 for integeration testing. I will shortly submit a patch to Apache 
Ranger to use it as well, as there are no kerberos integration tests done there.

Colm.

On Wed, May 17, 2017 at 3:32 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 17/05/2017 à 15:06, Zheng, Kai a écrit :
> > Good ask. Maybe we could address questions like such:
> > 1. How many issues we fixed since RC2 release, any features we've added?
> > 2. A summary about Kerby and high level functionalities list?
> > 3. Some links to the release artifacts and project.
> >
> > Not sure if any best practice here.
>
> The best practice is to send an announcement on annou...@apache.org, 
> but you already know that.
>
> You may want to be a bit broader : please contact pr...@apache.org 
> (Sally Khudairi) if you want some more PR, they would be pleased to 
> help you drafting something that will be pushed to other channels.
>
>
> That being said, you should also start thinking about moving Kerby to 
> a TLP, now that 1.0 is out. Please consider doing so while discussing 
> with press@a.o, so that both moves are done at the same time, in order 
> to have more spotlights on the project.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Good ask. Maybe we could address questions like such:
1. How many issues we fixed since RC2 release, any features we've added?
2. A summary about Kerby and high level functionalities list?
3. Some links to the release artifacts and project.

Not sure if any best practice here. 

We can get back to you tomorrow on this, to prepare a draft for you to refine.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, May 17, 2017 8:35 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

What kind of announcement did you have in mind?

Colm.

On Wed, May 17, 2017 at 12:51 PM, Zheng, Kai  wrote:

> Cool. Thanks Colm and Emmanuel. Is there any going to have an 
> announcement message?
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, May 17, 2017 6:52 PM
> To: kerby@directory.apache.org
> Subject: Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)
>
> Yes, looks good thanks!
>
> Colm.
>
> On Wed, May 17, 2017 at 11:00 AM, Emmanuel Lécharny 
> 
> wrote:
>
> > That should be OK now. Can you check ?
> >
> >
> > Le 17/05/2017 à 11:40, Colm O hEigeartaigh a écrit :
> > > No the staging site is fine - the problem is that I don't see the 
> > > staging site pushed to directory.apache.org. For example, the 
> > > staging site has Kerby "1.0.0" since yesterday, but the main 
> > > published site still has "1.0.0-RC2".
> > >
> > > Colm.
> > >
> > > On Wed, May 17, 2017 at 10:33 AM, Emmanuel Lécharny 
> > >  > >
> > > wrote:
> > >
> > >>
> > >> Le 17/05/2017 à 10:32, Colm O hEigeartaigh a écrit :
> > >>> Is it possible to push the staging site manually? I'm still 
> > >>> waiting to
> > >> see
> > >>> the updates I made propagate through...
> > >> What commit don't you see on the staging site ?
> > >>
> > >> --
> > >>
> > >> Emmanuel Lecharny
> > >>
> > >> Symas.com
> > >> directory.apache.org
> > >>
> > >>
> > >
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Cool. Thanks Colm and Emmanuel. Is there any going to have an announcement 
message?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, May 17, 2017 6:52 PM
To: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

Yes, looks good thanks!

Colm.

On Wed, May 17, 2017 at 11:00 AM, Emmanuel Lécharny 
wrote:

> That should be OK now. Can you check ?
>
>
> Le 17/05/2017 à 11:40, Colm O hEigeartaigh a écrit :
> > No the staging site is fine - the problem is that I don't see the 
> > staging site pushed to directory.apache.org. For example, the 
> > staging site has Kerby "1.0.0" since yesterday, but the main 
> > published site still has "1.0.0-RC2".
> >
> > Colm.
> >
> > On Wed, May 17, 2017 at 10:33 AM, Emmanuel Lécharny 
> >  >
> > wrote:
> >
> >>
> >> Le 17/05/2017 à 10:32, Colm O hEigeartaigh a écrit :
> >>> Is it possible to push the staging site manually? I'm still 
> >>> waiting to
> >> see
> >>> the updates I made propagate through...
> >> What commit don't you see on the staging site ?
> >>
> >> --
> >>
> >> Emmanuel Lecharny
> >>
> >> Symas.com
> >> directory.apache.org
> >>
> >>
> >
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Maybe Jiajia could help check with this? Thanks Colm.

Sent from iPhone

> 在 2017年5月16日，下午9:14，Colm O hEigeartaigh  写道：
> 
> Thanks Emmanuel...where is the staging site?
> 
> Colm.
> 
> On Tue, May 16, 2017 at 1:12 PM, Emmanuel Lécharny 
> wrote:
> 
>> 
>> 
>>> Le 16/05/2017 à 11:44, Colm O hEigeartaigh a écrit :
>>> Yes, the release is done and available in Maven central + the dist. The
>>> website isn't updated yetis there anything I need to do to trigger
>> the
>>> update apart from checkin to the website svn?
>> 
>> If the staging site is ok, I can publish it. Just let me know, it's a 10
>> secs thing.
>> 
>> 
>> --
>> Emmanuel Lecharny
>> 
>> Symas.com
>> directory.apache.org
>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Any good luck so far? Thanks!

Sent from iPhone

> 在 2017年5月13日，下午9:54，Colm O hEigeartaigh  写道：
> 
> With all +1 votes, this vote passes. I'll do the release.
> 
> Colm.
> 
> On Fri, May 12, 2017 at 12:54 PM, Lucas Theisen 
> wrote:
> 
>> +1
>> 
>>> On May 12, 2017 1:28 AM, "Zeng, Frank"  wrote:
>>> 
>>> Build successfully.
>>> 
>>> Run kadmin, kinit, klist successfully.
>>> 
>>> 
>>> 
>>> non-binding +1 from me.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Frank
>>> 
>>> 
>>> 
>>> *From:* Colm O hEigeartaigh [mailto:cohei...@apache.org
>>> ]
>>> *Sent:* Wednesday, May 10, 2017 6:14 PM
>>> *To:* kerby@directory.apache.org; Apache Directory Developers List <
>>> d...@directory.apache.org>
>>> *Subject:* [VOTE] - Release Apache Kerby 1.0.0 (take II)
>>> 
>>> 
>>> 
>>> This is (the second) vote to release Apache Kerby 1.0.0. We had to cancel
>>> the first vote after Emmanuel identified some issues with the NOTICE +
>>> licenses for the two Kerby distributions. The distributions now correctly
>>> include the Netty NOTICEs and licenses of modified components, and SLF4J
>>> copyright notice + license.
>>> 
>>> Issues fixed:
>>> 
>>> https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
>>> 
>>> Maven Artifacts:
>>> 
>>> https://repository.apache.org/content/repositories/orgapache
>>> directory-1130/
>>> 
>>> In particular the source:
>>> 
>>> https://repository.apache.org/content/repositories/orgapache
>>> directory-1130/org/apache/kerby/kerby-all/1.0.0/
>>> 
>>> Git tag:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=directory-kerby.gi
>>> t;a=commit;h=b0e8f9da3cdb494c82d62c956ee35a53a52ac0ce
>>> 
>>> 
>>> 
>>> +1 from me.
>>> 
>>> Colm.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Colm O hEigeartaigh
>>> 
>>> Talend Community Coder
>>> http://coders.talend.com
>>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

RE: PKINIT with certificates

[Zheng, Kai]

Hi Jim,

Kerby hasn't supported certificate based PKINIT yet, though it does have lots 
of codes about PKI prepared for it. We did receive some user interests but the 
work is a very hard taking so the effort is blocked by more important tasks. 
Not sure about how Kerby PKINIT would help you.

Regards,
Kai

-Original Message-
From: Jim Shi [mailto:hj...@yahoo.com.INVALID] 
Sent: Friday, May 12, 2017 1:50 AM
To: kerby@directory.apache.org
Subject: PKINIT with certificates

Hi, May I ask:
1) Does Kerby support certificate based PKINIT?2) Does Kerby support Elliptic 
Curve certificate?
Thanks
Jim

RE: kadmin-remote branch status

[Zheng, Kai]

Hi Colm,

Thanks for asking! We haven't worked on that for quite some time because there 
is no user interests for that time. There are some commands already workable 
but not compatible with MIT Kerberos yet. The branch hasn't been merged because 
we don't want to affect 1.0.0 release. 

Do you have some use cases that need the functionality?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, May 11, 2017 9:56 PM
To: kerby@directory.apache.org
Subject: kadmin-remote branch status

Hi all,

What is the current status of the kadmin-remote branch? Is it merged to master 
or if not is there a plan to do so?

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Thanks Colm for coming to this step!

My colleagues have given it more tests and verified it works fine. 

So my +1 on the release.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, May 10, 2017 8:38 PM
To: Apache Directory Developers List ; 
cohei...@apache.org; kerby@directory.apache.org
Subject: RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

+1

Items checked:

1.  Built successfully with jdk1.8.0_40

2.  All tests passed.

3.  Checked the tools.

Thanks
Jiajia

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, May 10, 2017 6:14 PM
To: kerby@directory.apache.org; Apache Directory Developers List 

Subject: [VOTE] - Release Apache Kerby 1.0.0 (take II)

This is (the second) vote to release Apache Kerby 1.0.0. We had to cancel the 
first vote after Emmanuel identified some issues with the NOTICE + licenses for 
the two Kerby distributions. The distributions now correctly include the Netty 
NOTICEs and licenses of modified components, and SLF4J copyright notice + 
license.
Issues fixed:

https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1130/
In particular the source:

https://repository.apache.org/content/repositories/orgapachedirectory-1130/org/apache/kerby/kerby-all/1.0.0/
Git tag:

https://git-wip-us.apache.org/repos/asf?p=directory-kerby.git;a=commit;h=b0e8f9da3cdb494c82d62c956ee35a53a52ac0ce

+1 from me.
Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Questions about the release

[Zheng, Kai]

Hi Colm and Emmanuel,

Regarding Netty, what we used is the TCP/UDP network transport support, which 
should be one of its basic functionalities. We haven't used any other parts, 
like the one JBoss marshalling function. The relevant codes are in kerby KDC. 
Hope this helps.

Regards,
Kai 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, May 09, 2017 8:12 PM
To: kerby@directory.apache.org
Subject: Re: Questions about the release

I haven't. So I think I should include all "This product contains a modified 
portion" portions from the NOTICE file, but not "This product optionally 
depends on" from here:

https://github.com/netty/netty/blob/4.1/NOTICE.txt

? As well as any of the licenses that are referred.

Colm.

On Tue, May 9, 2017 at 12:46 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> > Thanks Emmanuel. The user would have to add zookeeper/nimbus in the 
> > poms before generating the distribution to add them, so I am going 
> > to remove these from the NOTICE file as they are not required.
> >
> > OK here are the changes I have made...please review:
> >
> > 1) The root NOTICE just includes the standard Apache copyright notice:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/NOTICE
> >
> > 2) The two "distributions" of "kdc-dist" and "tool-dist" have the
> following
> > NOTICE files:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/kdc-dist/NOTICE
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/tool-dist/NOTICE
> >
> > and the following identical license folders:
> >
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/tool-dist/licenses
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/kdc-dist/licenses
> >
> > We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the
> tool-dist,
> > so I think we are covered.
>
>
> Sounds good to me.
>
> Have you taken into account the transitive dependencies ? (ie, N&L for 
> things that are embedded in Netty).
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Questions about the release

[Zheng, Kai]

Hi Colm,

Thanks for this! 

>> Kai, is there a reason that the zookeeper + nimbus dependencies are not in 
>> the lib directories of the distributions?
This is a good question I happened to know the answer.

Yes we have already supported various KDC back ends, like the LDAP, ZK ones, 
but which one is to bundle in the KDC dist and used by default? It's hard to 
tell, because each one seems to need some time to mature. I'd suggest we take 
time to improve them when received user interests. So that's why we didn't put 
all the supported back ends in the dist.

Nimbus is another story, it's for the token support. It's not bundled by 
default because I'm not sure most users would want the token support.

Considering this release trouble, now I intend we don't bundle this plugins 
that involve external deps heavily, but it's just a thought. We can discuss 
about the way later. For now less change much better.

Thanks again.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, May 09, 2017 4:52 PM
To: kerby@directory.apache.org
Subject: Re: Questions about the release

OK I have made some changes based on my understanding of what is required.
Please correct me if I'm wrong!

Mockito, Hamcrest (junit) are test dependencies and are not required in the 
NOTICE file or to specify the license.

We bundle Netty and SLF4J in the distribution. So we have the SLF4J license 
included in "licenses" and mentioned in NOTICE, as well as the Netty NOTICE.

From what I can see from kerby-dist/kdc-dist/target/lib and 
kerby-dist/tool-dist/target/lib, all of the dependencies are covered.
However, in NOTICE we also have the "nimbus-jose-jwt," NOTICE and the "JLine" 
NOTICE (from Zookeeper). However, it appears we don't bundle either of these in 
the "lib" directories so I'm not sure why they are there.

Kai, is there a reason that the zookeeper + nimbus dependencies are not in the 
lib directories of the distributions?

Colm.

On Tue, May 9, 2017 at 7:35 AM, Zheng, Kai  wrote:

> Thanks Emmanuel and Colm! Could we lend your hands on this? Sure if 
> your bandwidth allows. We're much dummy in such things and seem to 
> have on confidence to get it right. :(
>
> For the long term, I would suggest we reorganize Kerby into two projects:
> kerby-kerb for the Kerberos core and library; kerby-kdc. The two 
> projects can be separately released in their own appropriate cycles. 
> For Kerby-kerb, it avoids any 3rd party deps.
>
> Regards,
> Kai
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Tuesday, May 09, 2017 7:17 AM
> To: kerby@directory.apache.org
> Subject: Re: Questions about the release
>
>
>
> 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
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Questions about the release

[Zheng, Kai]

Thanks Emmanuel and Colm! Could we lend your hands on this? Sure if your 
bandwidth allows. We're much dummy in such things and seem to have on 
confidence to get it right. :(

For the long term, I would suggest we reorganize Kerby into two projects: 
kerby-kerb for the Kerberos core and library; kerby-kdc. The two projects can 
be separately released in their own appropriate cycles. For Kerby-kerb, it 
avoids any 3rd party deps.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Tuesday, May 09, 2017 7:17 AM
To: kerby@directory.apache.org
Subject: Re: Questions about the release



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: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails

[Zheng, Kai]

e.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<mailto:l...@acme.com> for 
HTTP/app-srv.acme@acme.com<mailto: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<mailto:l...@acme.com> for 
HTTP/app-srv.acme@acme.com<mailto:HTTP/app-srv.acme@acme.com>


Cheers

Chris




"Zheng, Kai" ---08/05/2017 14:32:29---Got your point. Please read credential 
cache utility codes and see if any API doing so. Sent from iP

From: "Zheng, Kai" mailto:kai.zh...@intel.com>>
To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" 
mailto:kerby@directory.apache.org>>
Date: 08/05/2017 14:32
Subject: Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos 
Single Sign On.




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 
mailto:christopher.l...@ch.ibm.com>> 写道：


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" mailto:kai.zh...@intel.com>>
To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" 
mailto: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<mailto: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" 
mailto:kai.zh...@intel.com><mailto:kai.zh...@intel.com>>
To: 
"kerby@directory.apache.org<mailto:kerby@directory.apache.org><mailto:kerby@directory.apache.org>"
 
mailto:kerby@directory.apache.org><mailto: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<mailto:kerby@directory.apache.org><mailto: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 sig

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

[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 
mailto:christopher.l...@ch.ibm.com>> 写道：


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" mailto:kai.zh...@intel.com>>
To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" 
mailto: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<mailto: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" 
mailto:kai.zh...@intel.com><mailto:kai.zh...@intel.com>>
To: 
"kerby@directory.apache.org<mailto:kerby@directory.apache.org><mailto:kerby@directory.apache.org>"
 
mailto:kerby@directory.apache.org><mailto: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<mailto:kerby@directory.apache.org><mailto: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 

Re: Questions about the release

[Zheng, Kai]

It's a very good reading and I learned a lot. Thanks!!!

Sent from iPhone

> 在 2017年5月8日，下午7:23，Emmanuel Lécharny  写道：
> 
> 
> 
>> 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.
> 
> 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&L.
> 
> 
> 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&L, 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...)
> 
> 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&L for all the
> embedded components in our jars.
> 
> 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&L too.
> 
> 
> Last, not least, it's unecessary to embed N&L for component that aren't
> bundled, like tests, or tools we use to build the packages. One notable
> exception, for instance, would be antlr : it's a tool, so we don't have
> to add the antlr N&L in a source package, because we don't embed antlr
> in the source package. But when we run the build and generate a binary
> package after havig processed some antlr files, then we have to embed
> teh antlr N&L, because buidling the source will generate some file
> produced by antlr (typically myFile.g --(antlr)--> myFile.java) that
> contain some antlr dependency, and the binary package will require a
> antlr library to process the java file.
> 
> Why should we not add extraneous N&L 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 contaminating license, taht would make all our code GPL.
> That one of our user decide to embed a GPL component is not our
> business, but in any case, they expect our packahes to be AL 2.0, not GPL.
> 
> LGPL is slightly different, but for teh exact same reason, we can't
> embed such a component in our packages. What we can do though, and this
> is what we do for MINA, is to tell users : "ok, if you want to use this
> specific LGPL library which is required fr that specific functionality,
> then you have to build the package yoruself, using a specific flag". For
> MINA, we have a flag for the rxtx package, which is LGPL : building MINA
> with this package requires the user to run 'mvn clean install -Pserial"
> where the 'serial' flag will embed the rxtx library. But when we release
> MINA, we don't use this flag, so our packages never embed rxtx.
> 
> 
> I hope this is clear enough, but to be frank, this is not a simple
> thing, and this is my understanding on how it works...
> 
> 
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 

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

[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" mailto:kai.zh...@intel.com>>
To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" 
mailto: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<mailto: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

[Zheng, Kai]

ugh applying your patch in the trunk) , I 
>> think it's success now.  Could you take some time to check about it?
>> Here is the log:
>>
>> directory-kerby git:(trunk) ✗ . 
>> kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerberos/kerb
>> /server/MitIssueTest.sh kerberos.authGSSClientInit successful
>> 2017-05-04T20:44:06 set-error: -1765328234: entypes not supported
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for krb5_ccache_conf_data/realm-config@X-CACHECONF: in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for test-service/localh...@test.com in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for
>> krb5_ccache_conf_data/negative-cache/test-service\134/localhost\1...@test.com@X-CACHECONF:
>>  
>> in cache FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for krb5_ccache_conf_data/lkdc-hostname@X-CACHECONF: in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for krb5_ccache_conf_data/sitename@X-CACHECONF: in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for test-service/localh...@test.com in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-md5-deprecated not supported
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-md4-deprecated not supported
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-crc-deprecated not supported
>> 2017-05-04T20:44:06 Trying to find service kdc for realm TEST.COM 
>> flags 0
>> 2017-05-04T20:44:06 configuration file for realm TEST.COM found
>> 2017-05-04T20:44:06 submissing new requests to new host
>> 2017-05-04T20:44:06 host_create: setting hostname localhost
>> 2017-05-04T20:44:06 connecting to host: udp ::1:52534 (localhost)
>> tid: 0001
>> 2017-05-04T20:44:06 host_create: setting hostname localhost
>> 2017-05-04T20:44:06 Queuing host in future (in 3s), its the 2 address 
>> on the same name: udp 127.0.0.1:52534 (localhost) tid: 0002
>> 2017-05-04T20:44:06 writing packet: udp ::1:52534 (localhost) tid: 
>> 0001
>> 2017-05-04T20:44:06 reading packet: udp ::1:52534 (localhost) tid: 
>> 0001
>> 2017-05-04T20:44:06 host completed: udp ::1:52534 (localhost) tid: 
>> 0001
>> 2017-05-04T20:44:06 krb5_sendto_context TEST.COM done: 0 hosts 1 
>> packets 1 wc: 0.048927 nr: 0.000932 kh: 0.000814 tid: 0002
>> 2017-05-04T20:44:06 tkt: extract key 17/763641F3
>> 2017-05-04T20:44:06 set-error: -1765328353: Decrypt integrity check 
>> failed for checksum type hmac-sha1-96-aes128, key type
>> aes128-cts-hmac-sha1-96
>> 2017-05-04T20:44:06 tkt: extract key 17/3084A95C
>> 2017-05-04T20:44:06 krb5_get_credentials_with_flags: TEST.COM wc: 
>> 0.050317
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for krb5_ccache_conf_data/realm-config@X-CACHECONF: in cache 
>> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
>> for
>> krb5_ccache_conf_data/time-offset/test-service\134/localhost\1...@test.com@X-CACHECONF:
>>  
>> in cache FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
>> 2017-05-04T20:44:06 Setting up PFS for auth context
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-md5-deprecated not supported
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-md4-deprecated not supported
>> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
>> des-cbc-crc-deprecated not supported First kerberos.authGSSClientStep 
>> successful
>>
>> Thanks
>> Jiajia
>>
>> -Original Message-
>> From: Zheng, Kai [mailto:kai.zh...@intel.com]
>> Sent: Wednesday, May 3, 2017 7:29 PM
>> To: kerby@directory.apache.org
>> Subject: RE: MIT Kerberos compatibility
>>
>> Hi Marc,
>>
>> In case you're not aware of this, please check out the latest fix 
>> made by Jiajia. We thought your case may be different, but would be 
>> good to have a check before we can repeat/fix your case. Thanks

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

[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

[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 
mailto:kai.zh...@intel.com>> 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<mailto:cohei...@apache.org>]
Sent: Monday, May 08, 2017 6:19 PM
To: kerby@directory.apache.org<mailto: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 
mailto:kai.zh...@intel.com>> 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<mailto:cohei...@apache.org>]
> Sent: Monday, May 08, 2017 5:42 PM
> To: Zheng, Kai mailto:kai.zh...@intel.com>>
> Cc: kerby@directory.apache.org<mailto: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<http://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 
> mailto:kai.zh...@intel.com>> 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 
> > > mailto:kai.zh...@intel.com>> 写道：
> > >
> > > 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 
> > >> mailto:cohei...@apache.org>> 写道：
> > >>
> > >> 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.ClosedChannelE

RE: MIT Kerberos compatibility

[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, 

RE: MIT Kerberos compatibility

[Zheng, Kai]

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 
> 

RE: [VOTE] - Release Apache Kerby 1.0.0

[Zheng, Kai]

Hi Jiajia,

Thanks for your hard work and pushing on the release.

>> the kerby-dist module will copy the dependencies to the 
>> kerby-dist/kdc-dist/target/lib and kerby-dist/tool-dist/target/lib.
Could you sort out what kinds of 3rd party dependencies are involved here? 
Particularly in the view of Emmanuel's relevant points. Thanks!

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Monday, May 08, 2017 11:30 AM
To: kerby@directory.apache.org
Subject: RE: [VOTE] - Release Apache Kerby 1.0.0

>>>At this point, I don't know what we package : there is a kerby-dist 
>>>sub-project, which supposely generates the packages, but it's hard to 
>>>tell what is inside, without looking to the maven pom files and assembly 
>>>files. I'd like that to be explicit somewhere for people to check easily the 
>>>validity of the packages...

As Stefan said, we only distribute the source for Kerby. If people wants to run 
the shell(start-kdc.sh, kadmin.sh, kinit.sh ,klist.sh...), he should download 
the distributed source code, and run "mvn clean package -Pdist", after that, 
the kerby-dist module will copy the dependencies to the 
kerby-dist/kdc-dist/target/lib and kerby-dist/tool-dist/target/lib.

Thanks
Jiajia

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Sunday, May 7, 2017 11:12 PM
To: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0



Le 07/05/2017 à 13:08, Stefan Seelmann a écrit :
> On 05/06/2017 09:53 PM, Emmanuel Lécharny wrote:
>> but I can't cas a +1 : the N&L are lacking some required external 
>> licenses (MIT for mockito, qos.ch for slf4j, BSD for harmcrest, ASM 
>> is BSD, and bytebuddy depends on it, Junit is ECL, Netty has a NOTICE 
>> file just must be included - see
>> https://github.com/netty/netty/blob/4.1/NOTICE.txt- , and has *many* 
>> dependencies on other products, that must be listed if used -see
>> https://github.com/netty/netty/tree/4.1/license-)
> I don't think we have to list all those licenses. As far as I see for 
> Kerby we only distribute the source (which is ASLv2 only) and the JARs.
> We don't distribute any artifact that bundles any third-party 
> dependency. [1] clearly states: "Dependencies which are not included 
> in the distribution MUST NOT be added to LICENSE and NOTICE. As far as 
> LICENSE and NOTICE are concerned, only bundled bits matter."
>
> But maybe I'm wrong and Maven dependencies count as "bundled"?
It depends.

First of all, we *must* have different N&L files if we distribute sources on 
one side and a bnary package on another side. This is typically what we do with 
apacheDS : we have the source targ.gz and a binary (the installers). As they 
embed different components, they have differnet N&L files. For instance, the 
installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/LICENSE
file contains the antlr license while the root LICENSE file does not :
it makes totally sense because we don't have any generated antlr file in the 
source, while we have many in the installers.

All in all, this is the logic to follow :

* if a library is present in the package, and if its LICENSE is not AL 2.0, 
then add the LICENSE file in the package
* if a library is present in the package, and if there is a NOTICE file for 
this lib then it must be added in the package
* of course, we don't support any non-AL 2.0 compatible bundle (GPL/LGPL aren't 
accepted license)

There are specific cases : everything that is required to build the sources, 
and that will not generate files (à la antlr) don't need to get their N&L 
added. Same thing for the tests.

One more thing : we *may* distribute source only, but at some point, people 
will build it and embed the result in their product. It's fine if our source 
package does not include any N&L from bundles that are referenced by maven 
dependencies, as we don't bundle those dependencies in the resulting source tar 
gz. But at some point, people *will* consume a library, generated *from* the 
sources, and this library may content external dependencies : at this point, 
this library *MUST* contain all the required N&L.

At this point, I don't know what we package : there is a kerby-dist 
sub-project, which supposely generates the packages, but it's hard to tell what 
is inside, without looking to the maven pom files and assembly files. I'd like 
that to be explicit somewhere for people to check easily the validity of the 
packages...


--
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: MIT Kerberos compatibility

[Zheng, Kai]

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.
>>>&

Re: MIT Kerberos compatibility

[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.
>>>>> 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
>>>&

Re: MIT Kerberos compatibility

[Zheng, Kai]

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.
>>> 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)
>>> 
>>> I'm not sure why we are seeing UDP errors when it's disabled?
>>> 
>>> Colm.
>>> 
>>>> On Fri, May 5, 2017 at 3:57 PM, Li, Jiajia  wrote:
>>>> 
>>>> Hi Colm,
>>>> The shell client can't connect to kdc if the UDP is disabled.
>>>> We don't use Netty in default.
>>>> What's your test-cases? The same as the Marc's?
>>>> 
>>>> Thanks
>>>> Jiajia
>>>> 
>>>> -Original Message-
>>>> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
>>>> Sent: Friday, May 5, 2017 10:09 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,
>>>> 
>>>> What are the issues if UDP is disabled and we don't use Netty? I
>>>> tried doing this with my own test-cases and it didn't work, so it
>>>> would be good to get this fixed soon.
>>>> 
>>>> Colm.
>>>> 
>>>> On Fri, May 5, 2017 at 2:46 PM, Li, Jiajia 
>> wrote:
>>>> 
>>>>> Hi Marc,
>>>>>>>> - your KRB5 tracing looks quite different. What OS and
>>>>>>>> mit-kerberos
>>>>> version did you use?
>>>>> I use mac os and the python version is 2.7.10
>>>>> 
>>>>>>>> - your KRB5 tracing shows UDP comms between kerberos client and
>>>>>>&g

Re: MIT Kerberos compatibility

[Zheng, Kai]

I think we can check the tcp problem with our java client and mit client. If 
both work we still could proceed, otherwise we need fix soon. Note the python 
client looks like not an easy debug. Anyone familiar?

Sent from iPhone

> 在 2017年5月5日，下午10:09，Colm O hEigeartaigh  写道：
> 
> Hi Jiajia,
> 
> What are the issues if UDP is disabled and we don't use Netty? I tried
> doing this with my own test-cases and it didn't work, so it would be good
> to get this fixed soon.
> 
> Colm.
> 
>> On Fri, May 5, 2017 at 2:46 PM, Li, Jiajia  wrote:
>> 
>> Hi Marc,
>>>>> - your KRB5 tracing looks quite different. What OS and mit-kerberos
>> version did you use?
>> I use mac os and the python version is 2.7.10
>> 
>>>>> - your KRB5 tracing shows UDP comms between kerberos client and KDC,
>> despite the allowUDP = false setting
>>>>> in my test. I did this setting because I get different problems
>> without it, see the additional logs below. So,
>>>>> we must also be aware of networking problems at my side.
>> I enable the UDP and use netty network, there are some issues if UDP
>> disabled, you can create a JIRA for this and we can fix this issue in the
>> next release version.
>> 
>> The changes in my side as following:
>> 
>> protected boolean allowUdp() {
>>return true;
>> }
>> @Override
>> protected void prepareKdc() throws KrbException {
>>getKdcServer().setInnerKdcImpl(
>>new NettyKdcServerImpl(getKdcServer().getKdcSetting()));
>>super.prepareKdc();
>> }
>> 
>> Here is log of MitIssueTest:
>> [INFO] Running org.apache.kerby.kerberos.kerb.server.MitIssueTest
>> [nioEventLoopGroup-2-1] INFO io.netty.handler.logging.LoggingHandler -
>> [id: 0x2634fe6b] REGISTERED
>> [nioEventLoopGroup-2-1] INFO io.netty.handler.logging.LoggingHandler -
>> [id: 0x2634fe6b] BIND(0.0.0.0/0.0.0.0:53957)
>> [nioEventLoopGroup-2-1] INFO io.netty.handler.logging.LoggingHandler -
>> [id: 0x2634fe6b, /0:0:0:0:0:0:0:0:53957] ACTIVE
>> [main] INFO org.apache.kerby.kerberos.kdc.impl.NettyKdcServerImpl - Netty
>> kdc server started.
>> [nioEventLoopGroup-2-1] INFO io.netty.handler.logging.LoggingHandler -
>> [id: 0x2634fe6b, /0:0:0:0:0:0:0:0:53957] RECEIVED: [id: 0xdac7228b, /
>> 127.0.0.1:53961 => /127.0.0.1:53957]
>> [defaultEventExecutorGroup-4-1] INFO 
>> org.apache.kerby.kerberos.kerb.server.request.AsRequest
>> - AS_REQ ISSUE: authtime 1493991123792,dran...@test.com for krbtgt/
>> test@test.com
>> [main] INFO 
>> org.apache.kerby.kerberos.kerb.client.impl.DefaultInternalKrbClient
>> - Send to kdc success.
>> [main] INFO org.apache.kerby.kerberos.kerb.client.KrbClientBase - Storing
>> the tgt to the credential cache file.
>> [nioEventLoopGroup-5-1] INFO 
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest
>> - The preauth data is empty.
>> [nioEventLoopGroup-5-1] INFO org.apache.kerby.kerberos.kerb.server.KdcHandler
>> - KRB error occurred while processing request:Additional pre-authentication
>> required
>> [nioEventLoopGroup-5-1] INFO 
>> org.apache.kerby.kerberos.kerb.server.request.AsRequest
>> - AS_REQ ISSUE: authtime 1493991123859,test-service/localh...@test.com
>> for krbtgt/test@test.com
>> [nioEventLoopGroup-5-1] INFO 
>> org.apache.kerby.kerberos.kerb.server.request.TgsRequest
>> - TGS_REQ ISSUE: authtime 1493991142850,drankye for test-service/
>> localh...@test.com
>> 
>> Thanks
>> Jiajia
>> 
>> -Original Message-
>> From: Zheng, Kai
>> Sent: Friday, May 5, 2017 7:46 PM
>> To: kerby@directory.apache.org; Li, Jiajia 
>> Subject: RE: MIT Kerberos compatibility
>> 
>> Hi Marc,
>> 
>> Looks like this is quite environment related, could you fire an issue for
>> this? I would suggest we target it to 1.1.0, which can be done in June.
>> 
>> Regards,
>> Kai
>> 
>> -Original Message-
>> From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl]
>> Sent: Friday, May 05, 2017 4:44 PM
>> To: Li, Jiajia 
>> Cc: kerby@directory.apache.org
>> Subject: Re: MIT Kerberos compatibility
>> 
>> Hi Jiajia,
>> 
>> Great to read that you made progress on this issue and to see a working
>> config at your side. Below, I list my progress below (with trunk merged
>> into my MitIssue branch), but I am afraid we are not done yet.
>> 
>> Things that stand out:
>> 
>> - the kdc decoding error is solved, relative to the logs without your patch
>> 
>&g

RE: Kerby 1.0 GA

[Zheng, Kai]

Thanks for the catch, Colm. It looks like a mess and we should bring those 
backends back.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, May 05, 2017 7:45 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org; Li, Jiajia 
Subject: Re: Kerby 1.0 GA

Hi Kai,

I'll call a vote today if I get some feedback on the email I sent about the 
backends - Jiajia committed a merge which commented out most of the backends.

Colm.

On Fri, May 5, 2017 at 12:41 PM, Zheng, Kai  wrote:

> Sounds great. Thanks Colm! Do we need to vote before we have release 
> artifacts or after that? Hope we can make it soon and won't block the 
> Hadoop 3.0 Alpha3 releasing.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, May 05, 2017 4:38 PM
> To: Zheng, Kai 
> Cc: Li, Jiajia ; kerby@directory.apache.org
> Subject: Re: Kerby 1.0 GA
>
> If it's all the same, I'd prefer to use "1.0.0" as this is the more 
> common convention at Apache. Yes, no problem at all with minor 
> releases. We could release 1.0.1 or 1.1.0 etc.
>
> Colm.
>
> On Fri, May 5, 2017 at 1:52 AM, Zheng, Kai  wrote:
>
> > Thanks Colm for the taking!
> >
> >
> >
> > I thought both work for me meaning the same thing. If changing the 
> > POMs to point to 1.0.0-GA could be easier, maybe we could use it?
> >
> >
> >
> > By the way, after this major release, we could release often, given 
> > important bug fixes or features. I noticed left issues are all 
> > targeted to 2.0.0, we could have 1.1.0 version for some of the left
> issues.
> >
> >
> >
> > Regards,
> >
> > Kai
> >
> >
> >
> > *From:* Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > *Sent:* Thursday, May 04, 2017 10:22 PM
> > *To:* Li, Jiajia 
> > *Cc:* kerby@directory.apache.org; Zheng, Kai 
> >
> > *Subject:* Re: Kerby 1.0 GA
> >
> >
> >
> > Any thoughts on what the release version should be? We're using 
> > 1.0.0-GA in JIRA, but I'm thinking just "1.0.0" for the poms.
> >
> > Colm.
> >
> >
> >
> > On Thu, May 4, 2017 at 3:20 PM, Colm O hEigeartaigh 
> > 
> > wrote:
> >
> > Yes, I will take care of the release today.
> >
> > Colm.
> >
> >
> >
> > On Thu, May 4, 2017 at 2:16 PM, Li, Jiajia  wrote:
> >
> > Hi Colm,
> >
> > I've removed the open JIRAs to a future release.
> > Our network is very bad for dong the release process, so could take 
> > the release work?
> > 1.0.0 GA will used in the next Hadoop release version 
> > 3.0.0-alpha3(May 15), so we should finish the release before it.
> >
> > Thanks
> > Jiajia
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Thursday, May 4, 2017 7:33 PM
> > To: Zheng, Kai 
> > Cc: kerby@directory.apache.org
> > Subject: Re: Kerby 1.0 GA
> >
> > OK, I've merged a bunch of fixes and I'm now done for the 1.0.0-GA
> release.
> > I see there are still a few open JIRAs. When do you anticipate 
> > calling the vote?
> >
> > Colm.
> >
> > On Wed, May 3, 2017 at 1:01 PM, Colm O hEigeartaigh 
> > 
> > wrote:
> >
> > > There are a lot of open issues (including one "in progress") for 
> > > the 1.0.0-GA release in JIRA:
> > >
> > > https://issues.apache.org/jira/browse/DIRKRB/fixforversion/1233277
> > > 5
> > >
> > > It would be a good idea to go through the issues and decide which 
> > > will be fixed for the GA release, and which should be moved to a 
> > > future
> > release.
> > >
> > > Colm.
> > >
> > > On Sun, Apr 30, 2017 at 1:11 AM, Zheng, Kai 
> wrote:
> > >
> > >> This makes sense. The GA should clean such kinds of codes.
> > >>
> > >> Regards,
> > >> Kai
> > >>
> > >> -Original Message-
> > >> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > >> Sent: Wednesday, April 26, 2017 6:38 PM
> > >> To: kerby@directory.apache.org
> > >> Subject: Re: Kerby 1.0 GA
> > >>
> > >> One improvement I'd like to see before the 1.0 GA release is to 
> > >> improve the exception handling. There are many examples of catch 
> > >> statements that just have a printStackTrace() leading to NP

RE: MIT Kerberos compatibility

[Zheng, Kai]

; kerberos.authGSSClientInit successful
> 2017-05-04T20:44:06 set-error: -1765328234: entypes not supported
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for krb5_ccache_conf_data/realm-config@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for test-service/localh...@test.com in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for 
> krb5_ccache_conf_data/negative-cache/test-service\134/localhost\134@TE
> ST.COM@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for krb5_ccache_conf_data/lkdc-hostname@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for krb5_ccache_conf_data/sitename@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for test-service/localh...@test.com in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-md5-deprecated not supported
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-md4-deprecated not supported
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-crc-deprecated not supported
> 2017-05-04T20:44:06 Trying to find service kdc for realm TEST.COM 
> flags 0
> 2017-05-04T20:44:06 configuration file for realm TEST.COM found
> 2017-05-04T20:44:06 submissing new requests to new host
> 2017-05-04T20:44:06 host_create: setting hostname localhost
> 2017-05-04T20:44:06 connecting to host: udp ::1:52534 (localhost) tid: 
> 0001
> 2017-05-04T20:44:06 host_create: setting hostname localhost
> 2017-05-04T20:44:06 Queuing host in future (in 3s), its the 2 address 
> on the same name: udp 127.0.0.1:52534 (localhost) tid: 0002
> 2017-05-04T20:44:06 writing packet: udp ::1:52534 (localhost) tid: 
> 0001
> 2017-05-04T20:44:06 reading packet: udp ::1:52534 (localhost) tid: 
> 0001
> 2017-05-04T20:44:06 host completed: udp ::1:52534 (localhost) tid: 
> 0001
> 2017-05-04T20:44:06 krb5_sendto_context TEST.COM done: 0 hosts 1 
> packets 1 wc: 0.048927 nr: 0.000932 kh: 0.000814 tid: 0002
> 2017-05-04T20:44:06 tkt: extract key 17/763641F3
> 2017-05-04T20:44:06 set-error: -1765328353: Decrypt integrity check 
> failed for checksum type hmac-sha1-96-aes128, key type 
> aes128-cts-hmac-sha1-96
> 2017-05-04T20:44:06 tkt: extract key 17/3084A95C
> 2017-05-04T20:44:06 krb5_get_credentials_with_flags: TEST.COM wc: 
> 0.050317
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for krb5_ccache_conf_data/realm-config@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 set-error: -1765328243: Did not find credential 
> for 
> krb5_ccache_conf_data/time-offset/test-service\134/localhost\134@TEST.
> COM@X-CACHECONF: in cache 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> 2017-05-04T20:44:06 Setting up PFS for auth context
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-md5-deprecated not supported
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-md4-deprecated not supported
> 2017-05-04T20:44:06 set-error: -1765328234: Encryption type 
> des-cbc-crc-deprecated not supported First kerberos.authGSSClientStep 
> successful
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Zheng, Kai [mailto:kai.zh...@intel.com]
> Sent: Wednesday, May 3, 2017 7:29 PM
> To: kerby@directory.apache.org
> Subject: RE: MIT Kerberos compatibility
>
> Hi Marc,
>
> In case you're not aware of this, please check out the latest fix made by 
> Jiajia. We thought your case may be different, but would be good to have a 
> check before we can repeat/fix your case. Thanks.
> https://issues.apache.org/jira/browse/DIRKRB-625
>
> Regards,
> Kai
>
> -Original Message-
> From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl]
> Sent: Sunday, April 30, 2017 7:45 PM
> To: kerby@directory.apache.org
> Subject: Re: MIT Kerberos compatibility
>
> Hi Kai,
>
> The terminal output below is for the latest MIT Kerberos 1.15.1 (locally 
> built on Ubuntu Xenial). Before that, I also tested with the default Xenial 
> MIT Kerberos packages (1.13.2), with the same result. I did not try earlier 
> MIT Kerberos versions.
>
> Marc
>
> Op 29-04-17 om 21:42 schreef Mar

RE: Kerby 1.0 GA

[Zheng, Kai]

Sounds great. Thanks Colm! Do we need to vote before we have release artifacts 
or after that? Hope we can make it soon and won't block the Hadoop 3.0 Alpha3 
releasing.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, May 05, 2017 4:38 PM
To: Zheng, Kai 
Cc: Li, Jiajia ; kerby@directory.apache.org
Subject: Re: Kerby 1.0 GA

If it's all the same, I'd prefer to use "1.0.0" as this is the more common 
convention at Apache. Yes, no problem at all with minor releases. We could 
release 1.0.1 or 1.1.0 etc.

Colm.

On Fri, May 5, 2017 at 1:52 AM, Zheng, Kai  wrote:

> Thanks Colm for the taking!
>
>
>
> I thought both work for me meaning the same thing. If changing the 
> POMs to point to 1.0.0-GA could be easier, maybe we could use it?
>
>
>
> By the way, after this major release, we could release often, given 
> important bug fixes or features. I noticed left issues are all 
> targeted to 2.0.0, we could have 1.1.0 version for some of the left issues.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:cohei...@apache.org]
> *Sent:* Thursday, May 04, 2017 10:22 PM
> *To:* Li, Jiajia 
> *Cc:* kerby@directory.apache.org; Zheng, Kai 
>
> *Subject:* Re: Kerby 1.0 GA
>
>
>
> Any thoughts on what the release version should be? We're using 
> 1.0.0-GA in JIRA, but I'm thinking just "1.0.0" for the poms.
>
> Colm.
>
>
>
> On Thu, May 4, 2017 at 3:20 PM, Colm O hEigeartaigh 
> 
> wrote:
>
> Yes, I will take care of the release today.
>
> Colm.
>
>
>
> On Thu, May 4, 2017 at 2:16 PM, Li, Jiajia  wrote:
>
> Hi Colm,
>
> I've removed the open JIRAs to a future release.
> Our network is very bad for dong the release process, so could take 
> the release work?
> 1.0.0 GA will used in the next Hadoop release version 3.0.0-alpha3(May 
> 15), so we should finish the release before it.
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, May 4, 2017 7:33 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: Kerby 1.0 GA
>
> OK, I've merged a bunch of fixes and I'm now done for the 1.0.0-GA release.
> I see there are still a few open JIRAs. When do you anticipate calling 
> the vote?
>
> Colm.
>
> On Wed, May 3, 2017 at 1:01 PM, Colm O hEigeartaigh 
> 
> wrote:
>
> > There are a lot of open issues (including one "in progress") for the 
> > 1.0.0-GA release in JIRA:
> >
> > https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
> >
> > It would be a good idea to go through the issues and decide which 
> > will be fixed for the GA release, and which should be moved to a 
> > future
> release.
> >
> > Colm.
> >
> > On Sun, Apr 30, 2017 at 1:11 AM, Zheng, Kai  wrote:
> >
> >> This makes sense. The GA should clean such kinds of codes.
> >>
> >> Regards,
> >> Kai
> >>
> >> -Original Message-
> >> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> >> Sent: Wednesday, April 26, 2017 6:38 PM
> >> To: kerby@directory.apache.org
> >> Subject: Re: Kerby 1.0 GA
> >>
> >> One improvement I'd like to see before the 1.0 GA release is to 
> >> improve the exception handling. There are many examples of catch 
> >> statements that just have a printStackTrace() leading to NPEs down 
> >> the line. Apart from that, +1 from me on the release:
> >>
> >> find . -name "*.java" -path "*/main/*" | xargs grep 
> >> "printStackTrace()" | wc -l
> >> 30
> >>
> >> Colm.
> >>
> >> On Wed, Apr 26, 2017 at 3:31 AM, Zheng, Kai 
> wrote:
> >>
> >> > Sounds cool! Thanks Jiajia for taking this step forward.
> >> >
> >> > Regards,
> >> > Kai
> >> >
> >> > -Original Message-
> >> > From: Li, Jiajia [mailto:jiajia...@intel.com]
> >> > Sent: Wednesday, April 26, 2017 9:54 AM
> >> > To: kerby@directory.apache.org
> >> > Subject: RE: Kerby 1.0 GA
> >> >
> >> > Sorry for wrong typo.
> >> >
> >> > Hi all,
> >> >
> >> > We are going to start the Kerby 1.0.0 GA release progress.
> >> > It's more than one year since our last release 1.0.0-RC2, we have 
> >> > added lots of new features and bug fixes.
> >> > And this releas

RE: Kerby 1.0 GA

[Zheng, Kai]

Thanks Colm for the taking!

I thought both work for me meaning the same thing. If changing the POMs to 
point to 1.0.0-GA could be easier, maybe we could use it?

By the way, after this major release, we could release often, given important 
bug fixes or features. I noticed left issues are all targeted to 2.0.0, we 
could have 1.1.0 version for some of the left issues.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, May 04, 2017 10:22 PM
To: Li, Jiajia 
Cc: kerby@directory.apache.org; Zheng, Kai 
Subject: Re: Kerby 1.0 GA

Any thoughts on what the release version should be? We're using 1.0.0-GA in 
JIRA, but I'm thinking just "1.0.0" for the poms.
Colm.

On Thu, May 4, 2017 at 3:20 PM, Colm O hEigeartaigh 
mailto:cohei...@apache.org>> wrote:
Yes, I will take care of the release today.
Colm.

On Thu, May 4, 2017 at 2:16 PM, Li, Jiajia 
mailto:jiajia...@intel.com>> wrote:
Hi Colm,

I've removed the open JIRAs to a future release.
Our network is very bad for dong the release process, so could take the release 
work?
1.0.0 GA will used in the next Hadoop release version 3.0.0-alpha3(May 15), so 
we should finish the release before it.

Thanks
Jiajia

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Thursday, May 4, 2017 7:33 PM
To: Zheng, Kai mailto:kai.zh...@intel.com>>
Cc: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: Kerby 1.0 GA

OK, I've merged a bunch of fixes and I'm now done for the 1.0.0-GA release.
I see there are still a few open JIRAs. When do you anticipate calling the vote?

Colm.

On Wed, May 3, 2017 at 1:01 PM, Colm O hEigeartaigh 
mailto:cohei...@apache.org>>
wrote:

> There are a lot of open issues (including one "in progress") for the
> 1.0.0-GA release in JIRA:
>
> https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
>
> It would be a good idea to go through the issues and decide which will
> be fixed for the GA release, and which should be moved to a future release.
>
> Colm.
>
> On Sun, Apr 30, 2017 at 1:11 AM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
>> This makes sense. The GA should clean such kinds of codes.
>>
>> Regards,
>> Kai
>>
>> -Original Message-
>> From: Colm O hEigeartaigh 
>> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
>> Sent: Wednesday, April 26, 2017 6:38 PM
>> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
>> Subject: Re: Kerby 1.0 GA
>>
>> One improvement I'd like to see before the 1.0 GA release is to
>> improve the exception handling. There are many examples of catch
>> statements that just have a printStackTrace() leading to NPEs down
>> the line. Apart from that, +1 from me on the release:
>>
>> find . -name "*.java" -path "*/main/*" | xargs grep
>> "printStackTrace()" | wc -l
>> 30
>>
>> Colm.
>>
>> On Wed, Apr 26, 2017 at 3:31 AM, Zheng, Kai 
>> mailto:kai.zh...@intel.com>> wrote:
>>
>> > Sounds cool! Thanks Jiajia for taking this step forward.
>> >
>> > Regards,
>> > Kai
>> >
>> > -Original Message-
>> > From: Li, Jiajia [mailto:jiajia...@intel.com<mailto:jiajia...@intel.com>]
>> > Sent: Wednesday, April 26, 2017 9:54 AM
>> > To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
>> > Subject: RE: Kerby 1.0 GA
>> >
>> > Sorry for wrong typo.
>> >
>> > Hi all,
>> >
>> > We are going to start the Kerby 1.0.0 GA release progress.
>> > It's more than one year since our last release 1.0.0-RC2, we have
>> > added lots of new features and bug fixes.
>> > And this release will include some blocking issues for Hadoop and
>> > 1.0.0 GA will impact the next Hadoop release version 3.0.0-alpha3.
>> >
>> > Regards,
>> > Jiajia
>> >
>> > -Original Message-
>> > From: Li, Jiajia [mailto:jiajia...@intel.com<mailto:jiajia...@intel.com>]
>> > Sent: Wednesday, April 26, 2017 9:49 AM
>> > To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
>> > Subject: Kerby 1.0 GA
>> >
>> > Hi all,
>> >
>> > We are going to start the Kerby 1.0.0 GA release progress.
>> > It's more than one year since our last release 1.0.0-RC2, we have
>> > added lots of new features and bug fixes.
>> > And this release will include some blocking issues for Hadoop and
>> > 1.0.0 GA will impact the next Hadoop release version 3.0.0-alpha1.
>> >
>> > Regards,
>> > Jiajia
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: MIT Kerberos compatibility

[Zheng, Kai]

Hi Marc,

In case you're not aware of this, please check out the latest fix made by 
Jiajia. We thought your case may be different, but would be good to have a 
check before we can repeat/fix your case. Thanks.
https://issues.apache.org/jira/browse/DIRKRB-625

Regards,
Kai

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

Hi Kai,

The terminal output below is for the latest MIT Kerberos 1.15.1 (locally built 
on Ubuntu Xenial). Before that, I also tested with the default Xenial MIT 
Kerberos packages (1.13.2), with the same result. I did not try earlier MIT 
Kerberos versions.

Marc

Op 29-04-17 om 21:42 schreef Marc de Lignie:
>
> Hi Kai,
>
> Thanks for the response. I prepared a minimal config that reproduces 
> my problem.
>
> You can fetch the branch/commit from:
> https://github.com/vtslab/directory-kerby/commits/MitIssue
>
> This is relative to RC2, but I also tried this on trunk for my actual 
> project.
>
> This config produces the debug and error messages below.
>
> 1. For the terminal with the bash + python script $ klist Ticket 
> cache: FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> Default principal: dran...@test.com
>
> Valid starting ExpiresService principal
> 29-04-17 21:07:39  30-04-17 05:07:39  krbtgt/test@test.com
> renew until 29-04-17 21:07:39
>
> $ . 
> kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerberos/kerb/
> server/MitIssueTest.sh [15538] 1493491231.917606: Retrieving 
> dran...@test.com from FILE:/etc/krb5/user/1000/client.keytab (vno 0, 
> enctype 0) with result:
> 2/Key table file '/etc/krb5/user/1000/client.keytab' not found [15538] 
> 1493491231.917827: Retrieving dran...@test.com from 
> FILE:/etc/krb5/user/1000/client.keytab (vno 0, enctype 0) with result:
> 2/Key table file '/etc/krb5/user/1000/client.keytab' not found 
> kerberos.authGSSClientInit successful [15538] 1493491231.918185: 
> Getting credentials dran...@test.com -> test-service/localhost@ using 
> ccache FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
> [15538] 1493491231.918210: 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 (filename: 
> kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc)
> [15538] 1493491231.918226: Retrying dran...@test.com -> 
> test-service/localh...@test.com with result: -1765328243/Matching 
> credential not found (filename:
> kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc)
> [15538] 1493491231.918229: Server has referral realm; starting with 
> test-service/localh...@test.com [15538] 1493491231.918278: Retrieving 
> dran...@test.com -> krbtgt/test@test.com from 
> FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result:
> 0/Success
> [15538] 1493491231.918281: Starting with TGT for client realm: 
> dran...@test.com -> krbtgt/test@test.com [15538] 
> 1493491231.918301: Requesting tickets for 
> test-service/localh...@test.com, referrals on [15538] 
> 1493491231.918326: Generated subkey for TGS request:
> aes128-cts/FA30
> [15538] 1493491231.918359: etypes requested in TGS request: 
> aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, 
> rc4-hmac, camellia128-cts, camellia256-cts [15538] 1493491231.918484: 
> Encoding request body and padata into FAST request [15538] 
> 1493491231.918541: Sending request (836 bytes) to TEST.COM [15538] 
> 1493491231.918597: Resolving hostname localhost [15538] 
> 1493491231.918703: Initiating TCP connection to stream
> 127.0.0.1:44292
> [15538] 1493491231.918777: Sending TCP request to stream 
> 127.0.0.1:44292 [15538] 1493491231.922803: TCP error receiving from 
> stream
> 127.0.0.1:44292: 104/Connection reset by peer [15538] 
> 1493491231.922812: Terminating TCP connection to stream
> 127.0.0.1:44292
> [15538] 1493491231.922858: Sending initial UDP request to dgram
> 127.0.0.1:44292
> ('First kerberos.authGSSClientStep not successful', 
> GSSError(('Unspecified GSS failure.  Minor code may provide more 
> information', 851968), ("Cannot contact any KDC for realm 'TEST.COM'",
> -1765328228)))
>
> 2. For the terminal that runs mvn clean test -Dtest=MitIssueTest 
> Running org.apache.kerby.kerberos.kerb.server.MitIssueTest
> 2017-04-29 21:07:39,182 DEBUG [main] backend.AbstractIdentityBackend: 
> initialize called
> 2017-04-29 21:07:39,195 DEBUG [main] backend.AbstractIdentityBackend: 
> getIdentity called, principalName = krbtgt/test@test.com
> 2017-04-29 21:07:39,195 DEBUG [main] backend.AbstractIdentityBackend: 
> getIdentity failed, principalName = krbtgt/test@test.com
> 2017-04-29 21:07:39,212 DEBUG [main] backend.AbstractIdentityBackend: 
> addIdentity successful, principalName = krbtgt/test@test.com
> 2017-04-29 21:07:39,212 DEBUG [main] backend.AbstractIdentityBackend: 
> getIdentity called, 

RE: Kerby 1.0 GA

[Zheng, Kai]

This makes sense. The GA should clean such kinds of codes.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, April 26, 2017 6:38 PM
To: kerby@directory.apache.org
Subject: Re: Kerby 1.0 GA

One improvement I'd like to see before the 1.0 GA release is to improve the 
exception handling. There are many examples of catch statements that just have 
a printStackTrace() leading to NPEs down the line. Apart from that, +1 from me 
on the release:

find . -name "*.java" -path "*/main/*" | xargs grep "printStackTrace()" | wc -l
30

Colm.

On Wed, Apr 26, 2017 at 3:31 AM, Zheng, Kai  wrote:

> Sounds cool! Thanks Jiajia for taking this step forward.
>
> Regards,
> Kai
>
> -Original Message-
> From: Li, Jiajia [mailto:jiajia...@intel.com]
> Sent: Wednesday, April 26, 2017 9:54 AM
> To: kerby@directory.apache.org
> Subject: RE: Kerby 1.0 GA
>
> Sorry for wrong typo.
>
> Hi all,
>
> We are going to start the Kerby 1.0.0 GA release progress.
> It's more than one year since our last release 1.0.0-RC2, we have 
> added lots of new features and bug fixes.
> And this release will include some blocking issues for Hadoop and 
> 1.0.0 GA will impact the next Hadoop release version 3.0.0-alpha3.
>
> Regards,
> Jiajia
>
> -Original Message-
> From: Li, Jiajia [mailto:jiajia...@intel.com]
> Sent: Wednesday, April 26, 2017 9:49 AM
> To: kerby@directory.apache.org
> Subject: Kerby 1.0 GA
>
> Hi all,
>
> We are going to start the Kerby 1.0.0 GA release progress.
> It's more than one year since our last release 1.0.0-RC2, we have 
> added lots of new features and bug fixes.
> And this release will include some blocking issues for Hadoop and 
> 1.0.0 GA will impact the next Hadoop release version 3.0.0-alpha1.
>
> Regards,
> Jiajia
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: MIT Kerberos compatibility

[Zheng, Kai]

Thanks Marc for the details. We need to solve this for the 1.0 GA release. I'll 
look into it when get back to office. The fix shouldn't be big if we figure it 
out why the provided ASN1 packet isn't as expected while decoding.

What's your version, the MIT Kerberos client binary installation? I wonder it's 
introduced by new versions since we did test the case of MIT Kerberos client + 
Kerby KDC about two years ago.

Regards,
Kai 

-Original Message-
From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl] 
Sent: Sunday, April 30, 2017 3:42 AM
To: kerby@directory.apache.org
Subject: RE: MIT Kerberos compatibility


Hi Kai,

Thanks for the response. I prepared a minimal config that reproduces my problem.

You can fetch the branch/commit from:
https://github.com/vtslab/directory-kerby/commits/MitIssue

This is relative to RC2, but I also tried this on trunk for my actual project.

This config produces the debug and error messages below.

1. For the terminal with the bash + python script $ klist Ticket cache: 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
Default principal: dran...@test.com

Valid starting ExpiresService principal
29-04-17 21:07:39  30-04-17 05:07:39  krbtgt/test@test.com
 renew until 29-04-17 21:07:39

$ . 
kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerberos/kerb/server/MitIssueTest.sh
[15538] 1493491231.917606: Retrieving dran...@test.com from 
FILE:/etc/krb5/user/1000/client.keytab (vno 0, enctype 0) with result: 
2/Key table file '/etc/krb5/user/1000/client.keytab' not found [15538] 
1493491231.917827: Retrieving dran...@test.com from 
FILE:/etc/krb5/user/1000/client.keytab (vno 0, enctype 0) with result: 
2/Key table file '/etc/krb5/user/1000/client.keytab' not found 
kerberos.authGSSClientInit successful [15538] 1493491231.918185: Getting 
credentials dran...@test.com -> test-service/localhost@ using ccache 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc
[15538] 1493491231.918210: 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 (filename: 
kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc)
[15538] 1493491231.918226: Retrying dran...@test.com -> 
test-service/localh...@test.com with result: -1765328243/Matching credential 
not found (filename: 
kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc)
[15538] 1493491231.918229: Server has referral realm; starting with 
test-service/localh...@test.com [15538] 1493491231.918278: Retrieving 
dran...@test.com -> krbtgt/test@test.com from 
FILE:kerby-kerb/kerb-kdc-test/target/tmp/test-tkt.cc with result: 0/Success 
[15538] 1493491231.918281: Starting with TGT for client realm: 
dran...@test.com -> krbtgt/test@test.com [15538] 1493491231.918301: 
Requesting tickets for test-service/localh...@test.com, referrals on [15538] 
1493491231.918326: Generated subkey for TGS request: aes128-cts/FA30 [15538] 
1493491231.918359: etypes requested in TGS request: aes256-cts, aes128-cts, 
aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, 
camellia256-cts [15538] 1493491231.918484: Encoding request body and padata 
into FAST request [15538] 1493491231.918541: Sending request (836 bytes) to 
TEST.COM [15538] 1493491231.918597: Resolving hostname localhost [15538] 
1493491231.918703: Initiating TCP connection to stream
127.0.0.1:44292
[15538] 1493491231.918777: Sending TCP request to stream 127.0.0.1:44292 
[15538] 1493491231.922803: TCP error receiving from stream
127.0.0.1:44292: 104/Connection reset by peer [15538] 1493491231.922812: 
Terminating TCP connection to stream
127.0.0.1:44292
[15538] 1493491231.922858: Sending initial UDP request to dgram
127.0.0.1:44292
('First kerberos.authGSSClientStep not successful', GSSError(('Unspecified GSS 
failure.  Minor code may provide more information', 851968), ("Cannot contact 
any KDC for realm 'TEST.COM'",
-1765328228)))

2. For the terminal that runs mvn clean test -Dtest=MitIssueTest Running 
org.apache.kerby.kerberos.kerb.server.MitIssueTest
2017-04-29 21:07:39,182 DEBUG [main] backend.AbstractIdentityBackend: 
initialize called
2017-04-29 21:07:39,195 DEBUG [main] backend.AbstractIdentityBackend: 
getIdentity called, principalName = krbtgt/test@test.com
2017-04-29 21:07:39,195 DEBUG [main] backend.AbstractIdentityBackend: 
getIdentity failed, principalName = krbtgt/test@test.com
2017-04-29 21:07:39,212 DEBUG [main] backend.AbstractIdentityBackend: 
addIdentity successful, principalName = krbtgt/test@test.com
2017-04-29 21:07:39,212 DEBUG [main] backend.AbstractIdentityBackend: 
getIdentity called, principalName = kadmin/test@test.com
2017-04-29 21:07:39,212 DEBUG [main] backend.AbstractIdentityBackend: 
getIdentity failed, principalName = kadmin/test@test.com
2017-04-29 21:07:39,213 DEBUG [main] backend.AbstractIdentityBackend: 
addIdentity successful, principalName = kadmin/test@test.com
2017-0

RE: MIT Kerberos compatibility

[Zheng, Kai]

I know it was tested in the case of MIT client + Kerby KDC around some 
releases. 

Could you post your stack trace or more error/exception message here, or issue 
a ticket?

Regards,
Kai

-Original Message-
From: Marc de Lignie [mailto:m.c.delig...@xs4all.nl] 
Sent: Wednesday, April 26, 2017 2:42 PM
To: kerby@directory.apache.org
Subject: MIT Kerberos compatibility

Hi all,

Did anyone have any luck with using a MIT Kerberos client with Apache Kerby? 
Any documentation or directions?

What I am trying to achieve is:

  - generate a TGT and store in a credential cache with the Kerby client. No 
problems here

  - Use MIT Kerberos (with PyKerberos) to create a security context reusing the 
ticket cache. No visible problem.

  - use MIT Kerberos GSSAPI (with PyKerberos) to get a service ticket. 
This fails in the KDC on the first AS_REQ with a decoding error related to PA 
FAST

Any help appreciated,

Marc

RE: Kerby 1.0 GA

[Zheng, Kai]

Sounds cool! Thanks Jiajia for taking this step forward. 

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, April 26, 2017 9:54 AM
To: kerby@directory.apache.org
Subject: RE: Kerby 1.0 GA

Sorry for wrong typo.

Hi all,

We are going to start the Kerby 1.0.0 GA release progress. 
It's more than one year since our last release 1.0.0-RC2, we have added lots of 
new features and bug fixes.
And this release will include some blocking issues for Hadoop and 1.0.0 GA will 
impact the next Hadoop release version 3.0.0-alpha3.

Regards,
Jiajia

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, April 26, 2017 9:49 AM
To: kerby@directory.apache.org
Subject: Kerby 1.0 GA

Hi all,

We are going to start the Kerby 1.0.0 GA release progress. 
It's more than one year since our last release 1.0.0-RC2, we have added lots of 
new features and bug fixes.
And this release will include some blocking issues for Hadoop and 1.0.0 GA will 
impact the next Hadoop release version 3.0.0-alpha1.

Regards,
Jiajia

RE: kerby client on Android for SPNEGO authenticator for Chrome?

[Zheng, Kai]

Kerby was initiated with Android platform (Java environment) kept in mind, the 
client library is rather lightweight and should be easy to port. We haven't got 
it done yet, if you would have a try, the target module should be kerb-client 
(along with its deps). But if you meant for a native (C/C++) client library, 
Kerby shouldn't be the case, and you can look at MIT Kerberos.

Regards,
Kai

-Original Message-
From: Brian Vetter [mailto:bjvet...@hypori.com] 
Sent: Saturday, February 25, 2017 10:51 PM
To: kerby@directory.apache.org
Subject: kerby client on Android for SPNEGO authenticator for Chrome?

Anyone look at porting or using kerby to implement a SPNEGO authenticator for 
Chrome on Android? The Chromium team enabled the configuration of external 
authenticators for their Android version to support SPNEGO in particular. That 
said, there isn’t a kerberos client library available on Android AFAIK.

Has anyone attempted to port kerby to Android? Any known gotchas or 
dependencies that also need to be ported, or should I look at other 
alternatives for kerberos on Android?

RE: Prepare for 1.0.0-RC3

[Zheng, Kai]

Thank you Sammi for the taking and trying to move on. 

A question is, I'm not sure if it's required or smooth for you to do this 
without the committer ship. Anyway, please let we know if you need help, thanks.

Regards,
Kai

-Original Message-
From: Chen, Sammi [mailto:sammi.c...@intel.com] 
Sent: Wednesday, October 12, 2016 7:01 PM
To: 'kerby@directory.apache.org' 
Subject: RE: Prepare for 1.0.0-RC3

Hi All,

Since there are no more suggestions, I 'm going to start the RC3 release 
progress.

Regards,
Sammi

-Original Message-
From: Chen, Sammi 
Sent: Tuesday, September 27, 2016 10:23 AM
To: kerby@directory.apache.org
Subject: RE: Prepare for 1.0.0-RC3

Hi All,

Since Jiajia is taking leave, I will help to move on Kerby 1.0 release. Thanks 
for all your support. 

So far, following items are done, 
1. Update the readme and Javadoc Done
2. Do some test of tools  Done
3. Add logs to improve exception handle Done

Please suggest if anything missed or should be handled before the release. 

Thanks,
Sammi

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, July 27, 2016 2:53 PM
To: kerby@directory.apache.org
Subject: Prepare for 1.0.0-RC3


Hi all,

March 13, the 1.0.0-RC2 of Kerby was released. We're thinking about a new Kerby 
release(RC3).
>From Mar 13 to Jul 27, 60 JIRA issues were resolved, including following 
>important features:

1. Kerby authorization support. Gerard and Richard provided the large patch 2. 
XDR support 3. Some remote kadmin API(add, delete and list) 4. Some important 
fixes for JWT pre-authentication and SimpleKdcServer

I thinks the following issues should be solved before release:
1. Update the readme and javadoc
2. Do some tests of tools.
What else did I miss here?

How do you think about this?

Thanks
Jiajia

RE: Sync up

[Zheng, Kai]

An interesting idea indeed! Actually we Chinese have different naming scheme 
... sure it would be good when come to consider an English name, but that would 
only happen when it's really needed, for example, being in a school with many 
foreigner boys and girls ...

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, September 26, 2016 5:32 PM
To: kerby@directory.apache.org
Subject: Re: Sync up

Le 21/09/16 à 10:45, Zheng, Kai a écrit :
> Hi folks,
>
> I'd like to update that our tech lead Jiajia on Kerby project is taking a 
> long leave from the team and has delivered a very cute baby. Congratulations 
> to Jiajia! After some basic ramp up, Sammi will help with her role in my side 
> and try to move on. Thanks for the support.
>
> Regards,
> Kai
>
>
Just wondering : is it a baby-girl or a baby-boy ? And if it's a baby-girl what 
about calling her Mina, and Kerby for a baby-boy ? ;-) Ok, moving back under my 
stone ...

RE: Sync up

[Zheng, Kai]

Yeah, can't agree anymore! Thank you folks on behalf of Jiajia!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, September 21, 2016 10:22 PM
To: kerby@directory.apache.org
Subject: Re: Sync up

Le 21/09/16 à 15:09, SHAWN E SMITH a écrit :
> Thanks Emmanuel, I will never be able to look at a pregnant woman again 
> without considering the baby a release candidate.

When you are a developper, a baby is you most successful project, started with 
a scrum, ending with a release, followed by many, many patches and endless 
sleep deprivation ;-)

Sync up

[Zheng, Kai]

Hi folks,

I'd like to update that our tech lead Jiajia on Kerby project is taking a long 
leave from the team and has delivered a very cute baby. Congratulations to 
Jiajia! After some basic ramp up, Sammi will help with her role in my side and 
try to move on. Thanks for the support.

Regards,
Kai

RE: Kerby Remote KAdmin

[Zheng, Kai]

Hi Shawn,

I don't have a deep dive in that, but I thought what's been going is to get it 
work first in kerby remote client -> kerby admin server, in a protocol approach 
(XDR) aligned with MIT Kerberos admin. After that effort will be made to get it 
work with MIT admin using kerby admin client. Yan Yan is the major contributor 
but she had left the team so I'm not sure she will keep the contribution or 
not. Another contributor Qing from the team is working on a remote web UI 
interface at his willing.

Regards,
Kai

-Original Message-
From: SHAWN E SMITH [mailto:se...@psu.edu] 
Sent: Friday, August 05, 2016 10:14 PM
To: Apache Directory Developers List 
Subject: Kerby Remote KAdmin

All,

We've been working on getting the protocol working against an MIT Kerb 
instance.  Based on byte tracing in wireshark we think we're pretty close, but 
something is still not lining up cleanly.  Has anyone else done a deep dive on 
this that may be able to provide some feedback on what we're doing?  I'd like 
to find a good way to share what we're doing, but most of it is outside of core 
kerby so I'm not sure where to put it for others to see it.

Thanks,
Shawn

Any fool can write code that a computer can understand. Good programmers write 
code that humans can understand.
--Martin Fowler 

Shawn Smith
Director of Software Engineering
Administrative Information Services
814-321-5227
se...@psu.edu

https://keybase.io/ussmith

RE: Prepare for 1.0.0-RC3

[Zheng, Kai]

Maybe we could release this version as 1.0.0 directly? Any concern? I don't see 
any. We could claim the authorization feature and remote kadmin support as 
[EXPERIMENTAL]. 

Sorry too busy recently and don't have bandwidth on this. Hope it can move 
forward anyway.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, July 27, 2016 3:20 PM
To: kerby@directory.apache.org
Subject: Re: Prepare for 1.0.0-RC3

Le 27/07/16 à 08:52, Li, Jiajia a écrit :
> Hi all,
>
> March 13, the 1.0.0-RC2 of Kerby was released. We're thinking about a new 
> Kerby release(RC3).
> From Mar 13 to Jul 27, 60 JIRA issues were resolved, including following 
> important features:
>
> 1. Kerby authorization support. Gerard and Richard provided the large 
> patch 2. XDR support 3. Some remote kadmin API(add, delete and list) 
> 4. Some important fixes for JWT pre-authentication and SimpleKdcServer
>
> I thinks the following issues should be solved before release:
> 1. Update the readme and javadoc
> 2. Do some tests of tools.
> What else did I miss here?
>
> How do you think about this?

Hi Jiajia,

this is all good news !

However, I would suggest strongly that for the next iteration of Kerby (ie, 2.0 
or whatever fits your need), you stop using RC when you add features in the 
project. There is nothing wrong in releasing many incremental versions (1.0, 
2.0, 3.0..., à la Firefox/Chrome), even if it's every few months. OTOH, cutting 
3 RCs with added features is conveying a mixed messages to users.

I'm not asking Kerby people to stop doing so know, the train is already on its 
way, I'm just suggesting a different approach in the near future :-)

Many thanks and keep going the good work !

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Thanks Richard, this explains and makes sense.

Colm, would you think we’re aligned?

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Tuesday, July 26, 2016 1:03 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org; cohei...@apache.org; Richard Feezel 

Subject: Re: JWT pre-authentication - get JWT token on service side

Kai,

Here's what RFC 7751 has to say about copying authorization data from ticket to 
ticket:


   The Kerberos protocol allows clients to submit arbitrary

   authorization data for a KDC to insert into a Kerberos ticket.  These

   client-requested authorization data allow the client to express

   authorization restrictions that the application service will

   interpret.  With few exceptions, the KDC can safely copy these

   client-requested authorization data to the issued ticket without

   necessarily inspecting, interpreting, or filtering their contents.



The "few exceptions" I believe involve items which require some sort of 
signature attached by the KDC. These MUST be validated by a KDC upon receipt, 
and generated in any ticket issued by a KDC. Examples include AD-KDC-ISSUED and 
(the new) AD-CAMMAC. These types are intended to EXPAND the authorization of 
the client's use of the target service and therefore cannot be blindly copied 
from one ticket to another.

On Thu, Jul 21, 2016 at 4:44 AM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
>> I'm not convinced that the authorization data should be copied from TGT to 
>> Service Ticket.

I do believe so. If authz data can't be carried thru TGT to service ticket, how 
server to get authz data in Kerberos domain?

@Richard, could you help clarify about this? I believe you have the experience.

>> For example, the JWT token could contain some roles targeted at the KDC (via 
>> the audience of the token). Adding this data to service tickets would mean 
>> that the roles only intended for the KDC could now be applied to services 
>> etc.

It's a good thought. If you'd check the token-preauth draft, it actually said a 
token derivation should be put into ticket, not the token itself. It means, 
token attributes targeted to KDC should be removed from the derived token.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Monday, July 18, 2016 7:15 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

I'm not convinced that the authorization data should be copied from TGT to 
Service Ticket. For example, the JWT token could contain some roles targeted at 
the KDC (via the audience of the token). Adding this data to service tickets 
would mean that the roles only intended for the KDC could now be applied to 
services etc.

Colm.



On Thu, Jul 14, 2016 at 11:27 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

> Hi Colm,
>
> Sorry for the very late response. I'm just back from a travel. My
> answers to your questions are yes, and it's great if we could make it
> all work seamlessly!
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Friday, July 08, 2016 5:16 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> > For example, when the identity token is used to issue a tgt, does a
> > token
> derivation of the useful attributes generated and put into the issued tgt?
>
> By putting the token derivation into the issued TGT, are you referring
> to inserting it into the authorization data (as for the access token
> case)? If so, then not yet, but I have some code locally that should
> work that I will submit shortly.
>
> > When the tgt is used to issue a service ticket, does the token
> > derivation
> be put into the issued service tgt?
>
> Right now, no. Should we copy the authorization data of the TGT into
> the service ticket?
>
> Colm.
>
> On Wed, Jul 6, 2016 at 5:06 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
> > Sorry Colm, for the late replying.
> >
> > I thought identity token not only can do the authentication for the
> > client instead of user password, but also can do the similar thing
> > or even more than access token. It can also carry some useful
> > attributes and the attributes should also be able to pass down to
> > app server side for the similar thing. However, I haven't checked
> > the existing codes yet and not sure we did all the thing to make it
> > work that way. For example, when the identity t

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

>> I'm not convinced that the authorization data should be copied from TGT to 
>> Service Ticket.

I do believe so. If authz data can't be carried thru TGT to service ticket, how 
server to get authz data in Kerberos domain? 

@Richard, could you help clarify about this? I believe you have the experience.

>> For example, the JWT token could contain some roles targeted at the KDC (via 
>> the audience of the token). Adding this data to service tickets would mean 
>> that the roles only intended for the KDC could now be applied to services 
>> etc.

It's a good thought. If you'd check the token-preauth draft, it actually said a 
token derivation should be put into ticket, not the token itself. It means, 
token attributes targeted to KDC should be removed from the derived token.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, July 18, 2016 7:15 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

I'm not convinced that the authorization data should be copied from TGT to 
Service Ticket. For example, the JWT token could contain some roles targeted at 
the KDC (via the audience of the token). Adding this data to service tickets 
would mean that the roles only intended for the KDC could now be applied to 
services etc.

Colm.



On Thu, Jul 14, 2016 at 11:27 PM, Zheng, Kai  wrote:

> Hi Colm,
>
> Sorry for the very late response. I'm just back from a travel. My 
> answers to your questions are yes, and it's great if we could make it 
> all work seamlessly!
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, July 08, 2016 5:16 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> > For example, when the identity token is used to issue a tgt, does a 
> > token
> derivation of the useful attributes generated and put into the issued tgt?
>
> By putting the token derivation into the issued TGT, are you referring 
> to inserting it into the authorization data (as for the access token 
> case)? If so, then not yet, but I have some code locally that should 
> work that I will submit shortly.
>
> > When the tgt is used to issue a service ticket, does the token 
> > derivation
> be put into the issued service tgt?
>
> Right now, no. Should we copy the authorization data of the TGT into 
> the service ticket?
>
> Colm.
>
> On Wed, Jul 6, 2016 at 5:06 PM, Zheng, Kai  wrote:
>
> > Sorry Colm, for the late replying.
> >
> > I thought identity token not only can do the authentication for the 
> > client instead of user password, but also can do the similar thing 
> > or even more than access token. It can also carry some useful 
> > attributes and the attributes should also be able to pass down to 
> > app server side for the similar thing. However, I haven't checked 
> > the existing codes yet and not sure we did all the thing to make it 
> > work that way. For example, when the identity token is used to issue 
> > a tgt, does a token derivation of the useful attributes generated 
> > and put into the issued tgt? When the tgt is used to issue a service 
> > ticket, does the token derivation be put into the issued service 
> > tgt? With such, you should be able to make the use case work via 
> > identity token, instead of access
> token, for the work around.
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Tuesday, July 05, 2016 9:56 PM
> > To: kerby@directory.apache.org
> > Subject: Re: JWT pre-authentication - get JWT token on service side
> >
> > Thanks Kai! A final question (I hope) on the identity token use-case.
> > Is the sole point of the signed JWT token here just to authenticate 
> > the client? In other words, the attributes defined in the JWT token 
> > are not really used (for the identity case)? I guess the KDC could 
> > interpret them in some way, although I'm not really sure what the 
> > use-case could be right now. I see a stronger use-case for the 
> > access token case, where we can insert authorization data that the 
> > service can
> interpret.
> >
> > Colm.
> >
> > On Mon, Jul 4, 2016 at 4:36 PM, Zheng, Kai  wrote:
> >
> > > The armor TGT is exactly used to provide a key to encrypt the 
> > > token to protect it from being stolen. You can obtain an armor TGT 
> > > via anonymous pkinit mechanism, right? You may wo

RE: Certificate Encoding

[Zheng, Kai]

Sorry I'm a little confused. What's the action or fix? 

@Jiajia, do you have some comment? Thx!

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, July 07, 2016 5:39 PM
To: Li, Jiajia 
Cc: kerby@directory.apache.org
Subject: Re: Certificate Encoding

Thanks Jiajia. The problem with the current logic of defaulting to "false"
is that we appear to be breaking the signature on the certificate. We should 
only set the critical value if it actually exists in the cert extension. I've 
updated the test to add cert path validation using the CA Cert. So even though 
the parsed cert is semantically equivalent to the original cert, cert path 
validation fails. If you remove the line in Extension.java to set critical then 
it passes.

Colm.

On Thu, Jul 7, 2016 at 4:31 AM, Li, Jiajia  wrote:

> Hi Colm,
>
> I've checked the two byte arrays, the different is when decoding the 
> Extension(Certificate-> TBSCertificate-> Extensions-> Extension), we 
> will set the default value "false" for "critical" item.
>
> Original Extension:
> SEQUENCE(2 elem)
> OBJECT IDENTIFIER2.5.29.19
> OCTET STRING(1 elem)
> SEQUENCE(0 elem)
>
> Decoded Extension:
> SEQUENCE(3 elem)
> OBJECT IDENTIFIER2.5.29.19
> BOOLEAN false
> OCTET STRING(1 elem)
>  SEQUENCE(0 elem)
>
> The Extension defined in In https://tools.ietf.org/html/rfc5280:
>Extension  ::=  SEQUENCE  {
> extnID  OBJECT IDENTIFIER,
> criticalBOOLEAN DEFAULT FALSE,
> extnValue   OCTET STRING
> -- contains the DER encoding of an ASN.1 value
> -- corresponding to the extension type identified
> -- by extnID
> }
>
> So we implement the Extension with the default Boolean value "false". 
> If remove the line67 in Extension.java, the test can be passed.
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, July 6, 2016 6:55 PM
> To: kerby@directory.apache.org
> Subject: Certificate Encoding
>
> Hi,
>
> I'm continuing to dig into the anonymous PKINIT code to try to get 
> certificate validation working. I've run into an issue with the way 
> certificates are marshalled to the Kerby Certificate type and back again.
> See the following @Ignore'd simple test:
>
>
> https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=comm
> it;h=88a7c956
>
> It just reads in an X.509Certificate, marshalls it as a 
> org.apache.kerby.x509.type.Certificate type, and then back again, and 
> checks the byte arrays. However the test for equality fails - the two 
> byte arrays are different.
>
> Any idea why this is? It's causing signature trust validation to fail 
> for PKINIT, as the certpath is not validating as a result.
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

Sorry for the very late response. I'm just back from a travel. My answers to 
your questions are yes, and it's great if we could make it all work seamlessly!

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, July 08, 2016 5:16 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

> For example, when the identity token is used to issue a tgt, does a 
> token
derivation of the useful attributes generated and put into the issued tgt?

By putting the token derivation into the issued TGT, are you referring to 
inserting it into the authorization data (as for the access token case)? If so, 
then not yet, but I have some code locally that should work that I will submit 
shortly.

> When the tgt is used to issue a service ticket, does the token 
> derivation
be put into the issued service tgt?

Right now, no. Should we copy the authorization data of the TGT into the 
service ticket?

Colm.

On Wed, Jul 6, 2016 at 5:06 PM, Zheng, Kai  wrote:

> Sorry Colm, for the late replying.
>
> I thought identity token not only can do the authentication for the 
> client instead of user password, but also can do the similar thing or 
> even more than access token. It can also carry some useful attributes 
> and the attributes should also be able to pass down to app server side 
> for the similar thing. However, I haven't checked the existing codes 
> yet and not sure we did all the thing to make it work that way. For 
> example, when the identity token is used to issue a tgt, does a token 
> derivation of the useful attributes generated and put into the issued 
> tgt? When the tgt is used to issue a service ticket, does the token 
> derivation be put into the issued service tgt? With such, you should 
> be able to make the use case work via identity token, instead of access 
> token, for the work around.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, July 05, 2016 9:56 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Thanks Kai! A final question (I hope) on the identity token use-case. 
> Is the sole point of the signed JWT token here just to authenticate 
> the client? In other words, the attributes defined in the JWT token 
> are not really used (for the identity case)? I guess the KDC could 
> interpret them in some way, although I'm not really sure what the 
> use-case could be right now. I see a stronger use-case for the access 
> token case, where we can insert authorization data that the service can 
> interpret.
>
> Colm.
>
> On Mon, Jul 4, 2016 at 4:36 PM, Zheng, Kai  wrote:
>
> > The armor TGT is exactly used to provide a key to encrypt the token 
> > to protect it from being stolen. You can obtain an armor TGT via 
> > anonymous pkinit mechanism, right? You may wonder why it would use 
> > the armor ticket for the encryption key, please think about 
> > otherwise how to equip clients and the kdc server with a shared but also 
> > secure key?
> > Armor mechanism is defined in Kerberos preauth related spec where 
> > the FAST and armored channel is defined.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Monday, July 04, 2016 11:26 PM
> > To: Zheng, Kai 
> > Cc: kerby@directory.apache.org
> > Subject: Re: JWT pre-authentication - get JWT token on service side
> >
> >
> > On Mon, Jul 4, 2016 at 4:01 PM, Zheng, Kai  > kai.zh...@intel.com>> wrote:
> > Regarding how to place the login module, I thought of putting it in 
> > kerb-client module in a separate package like 'jaas', would be good 
> > to do it because it sounds some useful now. We may have more such 
> > modules when more authentication mechanisms out to be supported in 
> > future. We often draft some codes in tests initially, when it looks 
> > good then we promote it to some better place.
> >
> > +1 to moving the TokenAuth login module to kerb-client
> >
> >
> > About supporting 'access' token in your case, I agree having some 
> > way to come up the initator GSS token out wrapping the service 
> > ticket to send out would be ideal and natural. That's why we're 
> > working on kerby based GSS support. Currently most of the work are 
> > done in the gssapi branch contributed by Wei Zhou, but I have never 
> > got the chance to play around with it and verify it works or not. 
> > Currently our guys are pretty busy with other takings, and will be 
&g

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Sorry Colm, for the late replying.

I thought identity token not only can do the authentication for the client 
instead of user password, but also can do the similar thing or even more than 
access token. It can also carry some useful attributes and the attributes 
should also be able to pass down to app server side for the similar thing. 
However, I haven't checked the existing codes yet and not sure we did all the 
thing to make it work that way. For example, when the identity token is used to 
issue a tgt, does a token derivation of the useful attributes generated and put 
into the issued tgt? When the tgt is used to issue a service ticket, does the 
token derivation be put into the issued service tgt? With such, you should be 
able to make the use case work via identity token, instead of access token, for 
the work around.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, July 05, 2016 9:56 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Thanks Kai! A final question (I hope) on the identity token use-case. Is the 
sole point of the signed JWT token here just to authenticate the client? In 
other words, the attributes defined in the JWT token are not really used (for 
the identity case)? I guess the KDC could interpret them in some way, although 
I'm not really sure what the use-case could be right now. I see a stronger 
use-case for the access token case, where we can insert authorization data that 
the service can interpret.

Colm.

On Mon, Jul 4, 2016 at 4:36 PM, Zheng, Kai  wrote:

> The armor TGT is exactly used to provide a key to encrypt the token to 
> protect it from being stolen. You can obtain an armor TGT via 
> anonymous pkinit mechanism, right? You may wonder why it would use the 
> armor ticket for the encryption key, please think about otherwise how 
> to equip clients and the kdc server with a shared but also secure key? 
> Armor mechanism is defined in Kerberos preauth related spec where the 
> FAST and armored channel is defined.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Monday, July 04, 2016 11:26 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
>
> On Mon, Jul 4, 2016 at 4:01 PM, Zheng, Kai  kai.zh...@intel.com>> wrote:
> Regarding how to place the login module, I thought of putting it in 
> kerb-client module in a separate package like 'jaas', would be good to 
> do it because it sounds some useful now. We may have more such modules 
> when more authentication mechanisms out to be supported in future. We 
> often draft some codes in tests initially, when it looks good then we 
> promote it to some better place.
>
> +1 to moving the TokenAuth login module to kerb-client
>
>
> About supporting 'access' token in your case, I agree having some way 
> to come up the initator GSS token out wrapping the service ticket to 
> send out would be ideal and natural. That's why we're working on kerby 
> based GSS support. Currently most of the work are done in the gssapi 
> branch contributed by Wei Zhou, but I have never got the chance to 
> play around with it and verify it works or not. Currently our guys are 
> pretty busy with other takings, and will be back to such tasks probably in a 
> month or so.
>
> Ok great, I can revisit the access token case at some stage in the 
> future when the GSS support is there. With regards to the "identity" 
> token case, the final thing I don't understand is the need to get an 
> initial armor TGT before getting a TGT using the Token. Is the sole 
> reason to prevent token leakage between the client and KDC? If so 
> wouldn't it suffice if the JWT token was encrypted?
> Thanks again,
>
> Colm.
>
>
> Regards,
> Kai
>
> -----Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> Sent: Monday, July 04, 2016 7:52 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Cc: Zheng, Kai mailto:kai.zh...@intel.com>>
> Subject: Re: JWT pre-authentication - get JWT token on service side 
> Thanks Jiajia, it's working well now. With regards to the LoginModule, 
> I made some changes to fix some NPEs. I also changed the logic 
> slightly, so that if the signing key is not specified, it just reads 
> in the token from the cache and writes it out "as is". If the token 
> was issued by say an OpenId Connect service, the client shouldn't be 
> signing it again. Perhaps the logic could be rewritten a bit, I'm open 
> to any ideas. Two questions on the LoginModule itself:
>
&

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

The armor TGT is exactly used to provide a key to encrypt the token to protect 
it from being stolen. You can obtain an armor TGT via anonymous pkinit 
mechanism, right? You may wonder why it would use the armor ticket for the 
encryption key, please think about otherwise how to equip clients and the kdc 
server with a shared but also secure key? Armor mechanism is defined in 
Kerberos preauth related spec where the FAST and armored channel is defined.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, July 04, 2016 11:26 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side


On Mon, Jul 4, 2016 at 4:01 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
Regarding how to place the login module, I thought of putting it in kerb-client 
module in a separate package like 'jaas', would be good to do it because it 
sounds some useful now. We may have more such modules when more authentication 
mechanisms out to be supported in future. We often draft some codes in tests 
initially, when it looks good then we promote it to some better place.

+1 to moving the TokenAuth login module to kerb-client


About supporting 'access' token in your case, I agree having some way to come 
up the initator GSS token out wrapping the service ticket to send out would be 
ideal and natural. That's why we're working on kerby based GSS support. 
Currently most of the work are done in the gssapi branch contributed by Wei 
Zhou, but I have never got the chance to play around with it and verify it 
works or not. Currently our guys are pretty busy with other takings, and will 
be back to such tasks probably in a month or so.

Ok great, I can revisit the access token case at some stage in the future when 
the GSS support is there. With regards to the "identity" token case, the final 
thing I don't understand is the need to get an initial armor TGT before getting 
a TGT using the Token. Is the sole reason to prevent token leakage between the 
client and KDC? If so wouldn't it suffice if the JWT token was encrypted?
Thanks again,

Colm.


Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Monday, July 04, 2016 7:52 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Cc: Zheng, Kai mailto:kai.zh...@intel.com>>
Subject: Re: JWT pre-authentication - get JWT token on service side
Thanks Jiajia, it's working well now. With regards to the LoginModule, I made 
some changes to fix some NPEs. I also changed the logic slightly, so that if 
the signing key is not specified, it just reads in the token from the cache and 
writes it out "as is". If the token was issued by say an OpenId Connect 
service, the client shouldn't be signing it again. Perhaps the logic could be 
rewritten a bit, I'm open to any ideas. Two questions on the LoginModule itself:

a) Perhaps the LoginModule should be moved from the "integration-test"
module? Or at least rename the module to something like "token-integration".
b) The LoginModule itself is not adding the KerberosPrincipal to the Subject, I 
think it should do this rather than have the test code add the Subject before 
the LoginModule is invoked.

Getting back to the use-case itself, I think the main scenario of interest is 
where the JWT Token is the "access" rather than "identity" case. So the client 
gets a token from an OpenId Connect authorization service targetted at a 
kerberized service. The client must then get a token for the service using the 
JWT token, etc.

Using the LoginModule + GSS approach as above works well for the "identity"
case, where we're using the JWT token to get a TGT. But how can it work for the 
case of using the JWT to get a Service ticket? With the first approach we're 
using the GSS API to get the service ticket, and I'm not sure if it's possible 
to change this to specify the JWT token somehow?

Colm.



On Mon, Jul 4, 2016 at 7:41 AM, Li, Jiajia 
mailto:jiajia...@intel.com>> wrote:

> I think this commit can fix the issue:
>
>
> https://git-wip-us.apache.org/repos/asf?p=directory-kerby.git;a=commit
> ;h=358340dd2a60a36a69988f1dd7c509cf585acdc8
>
> @Colm, can you check it?
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Li, Jiajia [mailto:jiajia...@intel.com<mailto:jiajia...@intel.com>]
> Sent: Monday, July 4, 2016 12:07 PM
> To: Zheng, Kai mailto:kai.zh...@intel.com>>; 
> kerby@directory.apache.org<mailto:kerby@directory.apache.org>;
> cohei...@apache.org<mailto:cohei...@apache.org>
> Subject: RE: JWT pre-authentication - get JWT token on service side
>
> Hi Colm,
>
> As Kai said, it's  a bug in new module.

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Regarding how to place the login module, I thought of putting it in kerb-client 
module in a separate package like 'jaas', would be good to do it because it 
sounds some useful now. We may have more such modules when more authentication 
mechanisms out to be supported in future. We often draft some codes in tests 
initially, when it looks good then we promote it to some better place.

About supporting 'access' token in your case, I agree having some way to come 
up the initator GSS token out wrapping the service ticket to send out would be 
ideal and natural. That's why we're working on kerby based GSS support. 
Currently most of the work are done in the gssapi branch contributed by Wei 
Zhou, but I have never got the chance to play around with it and verify it 
works or not. Currently our guys are pretty busy with other takings, and will 
be back to such tasks probably in a month or so.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, July 04, 2016 7:52 PM
To: kerby@directory.apache.org
Cc: Zheng, Kai 
Subject: Re: JWT pre-authentication - get JWT token on service side

Thanks Jiajia, it's working well now. With regards to the LoginModule, I made 
some changes to fix some NPEs. I also changed the logic slightly, so that if 
the signing key is not specified, it just reads in the token from the cache and 
writes it out "as is". If the token was issued by say an OpenId Connect 
service, the client shouldn't be signing it again. Perhaps the logic could be 
rewritten a bit, I'm open to any ideas. Two questions on the LoginModule itself:

a) Perhaps the LoginModule should be moved from the "integration-test"
module? Or at least rename the module to something like "token-integration".
b) The LoginModule itself is not adding the KerberosPrincipal to the Subject, I 
think it should do this rather than have the test code add the Subject before 
the LoginModule is invoked.

Getting back to the use-case itself, I think the main scenario of interest is 
where the JWT Token is the "access" rather than "identity" case. So the client 
gets a token from an OpenId Connect authorization service targetted at a 
kerberized service. The client must then get a token for the service using the 
JWT token, etc.

Using the LoginModule + GSS approach as above works well for the "identity"
case, where we're using the JWT token to get a TGT. But how can it work for the 
case of using the JWT to get a Service ticket? With the first approach we're 
using the GSS API to get the service ticket, and I'm not sure if it's possible 
to change this to specify the JWT token somehow?

Colm.



On Mon, Jul 4, 2016 at 7:41 AM, Li, Jiajia  wrote:

> I think this commit can fix the issue:
>
>
> https://git-wip-us.apache.org/repos/asf?p=directory-kerby.git;a=commit
> ;h=358340dd2a60a36a69988f1dd7c509cf585acdc8
>
> @Colm, can you check it?
>
> Thanks
> Jiajia
>
> -Original Message-
> From: Li, Jiajia [mailto:jiajia...@intel.com]
> Sent: Monday, July 4, 2016 12:07 PM
> To: Zheng, Kai ; kerby@directory.apache.org; 
> cohei...@apache.org
> Subject: RE: JWT pre-authentication - get JWT token on service side
>
> Hi Colm,
>
> As Kai said, it's  a bug in new module.
>
> >>However, if I look at the existing TokenAuthLoginModule, it just 
> >>adds
> the credential via:
> >>subject.getPublicCredentials().add(krbToken);
> >> It looks like GSS needs the TGT to be encoded in the Subject somehow?
>
> Yes, in the TokenAuthLoginModule, some credentials should be added to 
> subject private credentials.
> I will take some time to fix it.
>
> Regards,
> Jiajia
>
> -Original Message-
> From: Zheng, Kai
> Sent: Saturday, July 2, 2016 6:31 AM
> To: kerby@directory.apache.org; cohei...@apache.org; Li, Jiajia < 
> jiajia...@intel.com>
> Subject: RE: JWT pre-authentication - get JWT token on service side
>
> Hi Colm,
>
> I didn't check the codes yet, but generally the module should do the 
> similar thing as Krb5LoginModule in the post process of login. You 
> seemed to find a bug in the new module.
>
> @Jiajia, would you have some comments? Thanks.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, July 01, 2016 7:09 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> Thanks for your reply. Ok writing a JAAS LoginModule that wraps the 
> Kerby API is fine with me. However, if I look at the existing 
> TokenAuthLoginModule, it just adds the credential via:
>
> subject.getPublicCredentials().add(krbTo

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

I didn't check the codes yet, but generally the module should do the similar 
thing as Krb5LoginModule in the post process of login. You seemed to find a bug 
in the new module.

@Jiajia, would you have some comments? Thanks.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, July 01, 2016 7:09 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

Thanks for your reply. Ok writing a JAAS LoginModule that wraps the Kerby API 
is fine with me. However, if I look at the existing TokenAuthLoginModule, it 
just adds the credential via:

subject.getPublicCredentials().add(krbToken);

It looks like GSS needs the TGT to be encoded in the Subject somehow?
Please look at the following @Ignore'd test. I'm getting the Subject using the 
TokenAuthLoginModule and then attempting to get a service ticket using the GSS 
API and the Subject. It fails with "Caused by:
org.ietf.jgss.GSSException: No valid credentials provided (Mechanism level:
Failed to find any Kerberos tgt)":

https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=commit;h=68933ae0

Colm.


On Fri, Jul 1, 2016 at 2:22 AM, Zheng, Kai  wrote:

> Sorry for the late. Just got a chance looking at the codes closely.
>
> I thought it's clearly right in the following test, where it logins 
> first via jaas, then get tgt, then sgt, and then at last you wrap the 
> sgt in a gss token. It got the gss token (roughly a AppReq (of sgt) in 
> a token
> wrapper) and then let it be validated against a server key.
>
> @Test
> public void testGss() throws Exception {
> Subject clientSubject = loginClientUsingTicketCache();
> Set clientPrincipals = clientSubject.getPrincipals();
> Assert.assertFalse(clientPrincipals.isEmpty());
>
> // Get the TGT
> Set privateCredentials =
> clientSubject.getPrivateCredentials(KerberosTicket.class);
> Assert.assertFalse(privateCredentials.isEmpty());
> KerberosTicket tgt = privateCredentials.iterator().next();
> Assert.assertNotNull(tgt);
>
> // Get the service ticket
> KerberosClientExceptionAction action =
> new
> KerberosClientExceptionAction(clientPrincipals.iterator().next(),
> getServerPrincipal());
>
> byte[] kerberosToken = (byte[]) Subject.doAs(clientSubject, 
> action);
> Assert.assertNotNull(kerberosToken);
>
> validateServiceTicket(kerberosToken);
> }
>
> I don't think it's right here. The point is the bytes to validate at 
> the last step shouldn’t be the sgt directly, instead, it should be a 
> gss token of AppReq of the sgt. But you might ask how to generate the 
> gss token? I don't have better idea than the way used in the above 
> test method, that's to say, better to use GSSAPI layer in JRE 
> directly, since the Kerby one hasn't been ready yet.
>
> But how you proceed in the way as above? As you told in previous 
> emails, you don’t want to use jaas login modules, but rather use the 
> Kerby client api directly. I would suggest you still go starting with 
> jaas, doing everything you want in a jaas login module (like calling 
> kerby client api) and obtain a valid logined subject or security 
> context, and then do the left as you did in the above test method. It 
> should be able to work, like we did or will do in the token login module.
>
> @Test
> @org.junit.Ignore
> public void testKerbyClientAndGssService() throws Exception {
> KrbClient client = getKrbClient();
> client.init();
>
> try {
> // Get a service ticket using Kerby APIs
> TgtTicket tgt = client.requestTgt(getClientPrincipal(),
> getClientPassword());
> Assert.assertTrue(tgt != null);
>
> SgtTicket tkt = client.requestSgt(tgt, getServerPrincipal());
> Assert.assertTrue(tkt != null);
>
> Credential credential = new Credential(tkt, 
> tgt.getClientPrincipal());
> CredentialCache cCache = new CredentialCache();
> cCache.addCredential(credential);
> cCache.setPrimaryPrincipal(tgt.getClientPrincipal());
>
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> CredCacheOutputStream os = new CredCacheOutputStream(bout);
> cCache.store(bout);
> os.close();
>
> // Now validate the ticket using GSS
> validateServiceTicket(bout.toByteArray());
> } catch (Exception e) {
> e.printStackTrace();
> Assert.fail();
> 

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Sorry for the late. Just got a chance looking at the codes closely.

I thought it's clearly right in the following test, where it logins first via 
jaas, then get tgt, then sgt, and then at last you wrap the sgt in a gss token. 
It got the gss token (roughly a AppReq (of sgt) in a token wrapper) and then 
let it be validated against a server key.

@Test
public void testGss() throws Exception {
Subject clientSubject = loginClientUsingTicketCache();
Set clientPrincipals = clientSubject.getPrincipals();
Assert.assertFalse(clientPrincipals.isEmpty());

// Get the TGT
Set privateCredentials =
clientSubject.getPrivateCredentials(KerberosTicket.class);
Assert.assertFalse(privateCredentials.isEmpty());
KerberosTicket tgt = privateCredentials.iterator().next();
Assert.assertNotNull(tgt);

// Get the service ticket
KerberosClientExceptionAction action =
new 
KerberosClientExceptionAction(clientPrincipals.iterator().next(),
getServerPrincipal());

byte[] kerberosToken = (byte[]) Subject.doAs(clientSubject, action);
Assert.assertNotNull(kerberosToken);

validateServiceTicket(kerberosToken);
}

I don't think it's right here. The point is the bytes to validate at the last 
step shouldn’t be the sgt directly, instead, it should be a gss token of AppReq 
of the sgt. But you might ask how to generate the gss token? I don't have 
better idea than the way used in the above test method, that's to say, better 
to use GSSAPI layer in JRE directly, since the Kerby one hasn't been ready yet.

But how you proceed in the way as above? As you told in previous emails, you 
don’t want to use jaas login modules, but rather use the Kerby client api 
directly. I would suggest you still go starting with jaas, doing everything you 
want in a jaas login module (like calling kerby client api) and obtain a valid 
logined subject or security context, and then do the left as you did in the 
above test method. It should be able to work, like we did or will do in the 
token login module. 

@Test
@org.junit.Ignore
public void testKerbyClientAndGssService() throws Exception {
KrbClient client = getKrbClient();
client.init();

try {
// Get a service ticket using Kerby APIs
TgtTicket tgt = client.requestTgt(getClientPrincipal(), 
getClientPassword());
Assert.assertTrue(tgt != null);

SgtTicket tkt = client.requestSgt(tgt, getServerPrincipal());
Assert.assertTrue(tkt != null);

Credential credential = new Credential(tkt, 
tgt.getClientPrincipal());
CredentialCache cCache = new CredentialCache();
cCache.addCredential(credential);
cCache.setPrimaryPrincipal(tgt.getClientPrincipal());

ByteArrayOutputStream bout = new ByteArrayOutputStream();
CredCacheOutputStream os = new CredCacheOutputStream(bout);
cCache.store(bout);
os.close();

// Now validate the ticket using GSS
validateServiceTicket(bout.toByteArray());
} catch (Exception e) {
e.printStackTrace();
Assert.fail();
}
}

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, June 29, 2016 4:37 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Sure, no rush :-)

Colm.

On Wed, Jun 29, 2016 at 2:48 AM, Zheng, Kai  wrote:

> Hi Colm, I will look at this late of today. Hope it works for you.
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, June 28, 2016 10:00 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> Could you take a look at the @Ignore'd test-case I just committed:
>
>
> https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=blob
> diff;f=kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerbero
> s/kerb/server/GssInteropTest.java;h=7e0d269f6e0c19fb4f750dd98542a4d501
> 1e1dc5;hp=832d59dda4b0b0739ef5a1228da0b7bb20c10ab9;hb=1bce738d;hpb=79d
> 4a584129026bcf920dd1ae5c28c27c6971412
>
> It gets a SgtTicket using Kerby and tries to get the resulting service 
> token in byte array form to validate with GSS. Running the test leads to:
>
> Caused by: GSSException: Defective token detected (Mechanism level:
> GSSHeader did not find the right tag)
>
> I get the same error if I just do "sgtTicket.getTicket().encode()".
>
> Colm.
>
> On Thu, Jun 23, 2016 at 9:26 PM, Zheng, Kai  wrote:
>
> > I’m just back from my sleep. ☺
> >
> > Regarding how to get th

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm, I will look at this late of today. Hope it works for you. 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, June 28, 2016 10:00 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

Could you take a look at the @Ignore'd test-case I just committed:

https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=blobdiff;f=kerby-kerb/kerb-kdc-test/src/test/java/org/apache/kerby/kerberos/kerb/server/GssInteropTest.java;h=7e0d269f6e0c19fb4f750dd98542a4d5011e1dc5;hp=832d59dda4b0b0739ef5a1228da0b7bb20c10ab9;hb=1bce738d;hpb=79d4a584129026bcf920dd1ae5c28c27c6971412

It gets a SgtTicket using Kerby and tries to get the resulting service token in 
byte array form to validate with GSS. Running the test leads to:

Caused by: GSSException: Defective token detected (Mechanism level:
GSSHeader did not find the right tag)

I get the same error if I just do "sgtTicket.getTicket().encode()".

Colm.

On Thu, Jun 23, 2016 at 9:26 PM, Zheng, Kai  wrote:

> I’m just back from my sleep. ☺
>
> Regarding how to get the service ticket from SgtTicket object in 
> bytes, probably you do sgtTicket.getTicket().encode(). If it doesn’t 
> work, please reference the codes in CredCacheOutputStream.java to see 
> how it store a ticket in a file.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, June 23, 2016 11:25 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
>
> On Thu, Jun 23, 2016 at 3:28 PM, Zheng, Kai  kai.zh...@intel.com>> wrote:
> I see. Why you want to validate it using GSS on the client side? 
> Because the client gets it and then should just trust it, right? To 
> validate a service ticket needs the service key or keytab, which is 
> why I thought it could be on the server side.
>
> Just to test that it works! See the unit test called "unitGSSTest" here:
>
>
> https://github.com/coheigea/testcases/blob/master/apache/cxf/cxf-kerbe
> ros-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authenticatio
> n/AuthenticationTest.java
> Using the GSS API I do:
>
> byte[] ticket = (byte[]) Subject.doAs(clientSubject, action); ...
> validateServiceTicket(ticket);
>
>
> I got your scenario. Are you able to obtain the service ticket or not? You
> seem to because you said you can use a JWT token for that. But then you
> asked how to access the service ticket on the client side using the Kerby
> API. Did you have the SgtTicket in hand? If yes, I thought then you can
> extract something from it to put into the SOAP header. Could you point to
> the relevant spec about that? I may then have concrete idea to help.
>
> Yes I have the SgtTicket in hand. Now I want to extract the service ticket
> from this class as an array of bytes, similar to what I get above from
> Subject.doAs using the GSS API. I know how to put the Kerberos token in the
> SOAP header, my question is how to get it from SgtTicket in the first place
> :-)
> Thanks again for your help,
>
> Colm.
>
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> Sent: Thursday, June 23, 2016 9:40 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> On Thu, Jun 23, 2016 at 2:31 PM, Zheng, Kai  kai.zh...@intel.com>> wrote:
>
> >
> > >> How do I extract the token from SgtTicket that I can validate using
> GSS?
> > Sorry, but where do you want to do this? App client side or server side?
> > If on server side, I thought you have already made it, as your
> > previous email notified, being able to query/extract the authorization
> > data and get token from it. Would you clarify some bit?
> >
>
> On the client side. So what I want to do is use the Kerby API to get a
> service ticket (using a JWT token) and then extract the ticket from the KDC
> response + validate it using GSS. For example, for SOAP web services, the
> service ticket is inserted into the SOAP header of the web services call in
> BASE-64 format. So the question is, how can I get access to the service
> ticket on the client side using the Kerby API?
>
> Thanks,
>
> Colm.
>
>
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> > Sent: Thursday, June 23, 2016 7:59 PM
> > To: Zheng, Kai mailto:kai.zh...@intel.com>>
> > Cc: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> >

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

I’m just back from my sleep. ☺

Regarding how to get the service ticket from SgtTicket object in bytes, 
probably you do sgtTicket.getTicket().encode(). If it doesn’t work, please 
reference the codes in CredCacheOutputStream.java to see how it store a ticket 
in a file.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, June 23, 2016 11:25 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side


On Thu, Jun 23, 2016 at 3:28 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
I see. Why you want to validate it using GSS on the client side? Because the 
client gets it and then should just trust it, right? To validate a service 
ticket needs the service key or keytab, which is why I thought it could be on 
the server side.

Just to test that it works! See the unit test called "unitGSSTest" here:

https://github.com/coheigea/testcases/blob/master/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
Using the GSS API I do:

byte[] ticket = (byte[]) Subject.doAs(clientSubject, action);
...
validateServiceTicket(ticket);


I got your scenario. Are you able to obtain the service ticket or not? You seem 
to because you said you can use a JWT token for that. But then you asked how to 
access the service ticket on the client side using the Kerby API. Did you have 
the SgtTicket in hand? If yes, I thought then you can extract something from it 
to put into the SOAP header. Could you point to the relevant spec about that? I 
may then have concrete idea to help.

Yes I have the SgtTicket in hand. Now I want to extract the service ticket from 
this class as an array of bytes, similar to what I get above from Subject.doAs 
using the GSS API. I know how to put the Kerberos token in the SOAP header, my 
question is how to get it from SgtTicket in the first place :-)
Thanks again for your help,

Colm.


Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Thursday, June 23, 2016 9:40 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: JWT pre-authentication - get JWT token on service side

On Thu, Jun 23, 2016 at 2:31 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

>
> >> How do I extract the token from SgtTicket that I can validate using GSS?
> Sorry, but where do you want to do this? App client side or server side?
> If on server side, I thought you have already made it, as your
> previous email notified, being able to query/extract the authorization
> data and get token from it. Would you clarify some bit?
>

On the client side. So what I want to do is use the Kerby API to get a service 
ticket (using a JWT token) and then extract the ticket from the KDC response + 
validate it using GSS. For example, for SOAP web services, the service ticket 
is inserted into the SOAP header of the web services call in
BASE-64 format. So the question is, how can I get access to the service ticket 
on the client side using the Kerby API?

Thanks,

Colm.


>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Thursday, June 23, 2016 7:59 PM
> To: Zheng, Kai mailto:kai.zh...@intel.com>>
> Cc: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> On Wed, Jun 22, 2016 at 3:11 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com> kai.zh...@intel.com<mailto:kai.zh...@intel.com>>> wrote:
>
> Great question. Here what you need would be a login module using
> token, and the module will send the token to KDC for a TGT to get a
> SGT that's to be used in a GSS session. We have already the module,
> please look at TokenAuthLoginModule.
>
> From what I can see, the TokenAuthLoginModule just gets the TGT and
> not the SGT. However, I can get the service ticket easily enough via
> the Kerby API from this. How do I extract the token from SgtTicket
> that I can validate using GSS?
>
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org> cohei...@apache.org<mailto:cohei...@apache.org>>]
> Sent: Wednesday, June 22, 2016 9:36 PM
> To: 
> kerby@directory.apache.org<mailto:kerby@directory.apache.org><mailto:kerby@directory.apache.org<mailto:kerby@directory.apache.org>>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi all,
>
> Some more questions on this task:
>
> 1) Kai, you mentioned the AuthzToken type. Is this defined somewhere
> so that I can add it in to the Authorizatio

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

I see. Why you want to validate it using GSS on the client side? Because the 
client gets it and then should just trust it, right? To validate a service 
ticket needs the service key or keytab, which is why I thought it could be on 
the server side.

I got your scenario. Are you able to obtain the service ticket or not? You seem 
to because you said you can use a JWT token for that. But then you asked how to 
access the service ticket on the client side using the Kerby API. Did you have 
the SgtTicket in hand? If yes, I thought then you can extract something from it 
to put into the SOAP header. Could you point to the relevant spec about that? I 
may then have concrete idea to help.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, June 23, 2016 9:40 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

On Thu, Jun 23, 2016 at 2:31 PM, Zheng, Kai  wrote:

>
> >> How do I extract the token from SgtTicket that I can validate using GSS?
> Sorry, but where do you want to do this? App client side or server side?
> If on server side, I thought you have already made it, as your 
> previous email notified, being able to query/extract the authorization 
> data and get token from it. Would you clarify some bit?
>

On the client side. So what I want to do is use the Kerby API to get a service 
ticket (using a JWT token) and then extract the ticket from the KDC response + 
validate it using GSS. For example, for SOAP web services, the service ticket 
is inserted into the SOAP header of the web services call in
BASE-64 format. So the question is, how can I get access to the service ticket 
on the client side using the Kerby API?

Thanks,

Colm.


>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, June 23, 2016 7:59 PM
> To: Zheng, Kai 
> Cc: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi Kai,
>
> On Wed, Jun 22, 2016 at 3:11 PM, Zheng, Kai  kai.zh...@intel.com>> wrote:
>
> Great question. Here what you need would be a login module using 
> token, and the module will send the token to KDC for a TGT to get a 
> SGT that's to be used in a GSS session. We have already the module, 
> please look at TokenAuthLoginModule.
>
> From what I can see, the TokenAuthLoginModule just gets the TGT and 
> not the SGT. However, I can get the service ticket easily enough via 
> the Kerby API from this. How do I extract the token from SgtTicket 
> that I can validate using GSS?
>
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> Sent: Wednesday, June 22, 2016 9:36 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi all,
>
> Some more questions on this task:
>
> 1) Kai, you mentioned the AuthzToken type. Is this defined somewhere 
> so that I can add it in to the AuthorizationType class?
>
> 2) Currently, the TokenIssuer class asks the IdentityService for the 
> authorization data. However, the IdentityService doesn't have access 
> to the token. Is it reasonable default behaviour to insert the 
> received token in the TokenIssuer as the authorization data, and if 
> none exists fall back to ask the IdentityService for any authorization data?
>
> 3) I can extract the token on the service side using the GSS API in 
> the way suggested by Kai. However, how can I send the token to the KDC 
> on the client side using GSS?
>
> Thanks,
>
> Colm.
>
> On Fri, Jun 17, 2016 at 4:41 PM, Zheng, Kai  kai.zh...@intel.com>> wrote:
>
> > It's not a bug. It works that way, the temp value will be there only 
> > after you have decode/decrypt the part.
> >
> > Note SGT is used/consumed in app server side, and can be decrypted 
> > using the server ticket/key. I suggest you try this in the 
> > GssAppTest codes using the example code I provided in my last email, 
> > where you should be able to query/extract the authorization data. If 
> > you put the token in the authorization data, then after decoding it, 
> > you could extract token from it. I remembered we had defined the 
> > AuthzToken type for this actually but guess it's not used yet.
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org cohei...@apache.org>]
> > Sent: Friday, June 17, 2016 7:21 PM
> > To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> > Subject: Re: JWT pre-aut

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

Yes you’re right. The login module assumes some ones don’t want to touch the 
low level, but if otherwise like you, using the Kerby library directly should 
also work having the most flexibility.

>> How do I extract the token from SgtTicket that I can validate using GSS?
Sorry, but where do you want to do this? App client side or server side? If on 
server side, I thought you have already made it, as your previous email 
notified, being able to query/extract the authorization data and get token from 
it. Would you clarify some bit?

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, June 23, 2016 7:59 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

On Wed, Jun 22, 2016 at 3:11 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

Great question. Here what you need would be a login module using token, and the 
module will send the token to KDC for a TGT to get a SGT that's to be used in a 
GSS session. We have already the module, please look at TokenAuthLoginModule.

From what I can see, the TokenAuthLoginModule just gets the TGT and not the 
SGT. However, I can get the service ticket easily enough via the Kerby API from 
this. How do I extract the token from SgtTicket that I can validate using GSS?


Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Wednesday, June 22, 2016 9:36 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi all,

Some more questions on this task:

1) Kai, you mentioned the AuthzToken type. Is this defined somewhere so that I 
can add it in to the AuthorizationType class?

2) Currently, the TokenIssuer class asks the IdentityService for the 
authorization data. However, the IdentityService doesn't have access to the 
token. Is it reasonable default behaviour to insert the received token in the 
TokenIssuer as the authorization data, and if none exists fall back to ask the 
IdentityService for any authorization data?

3) I can extract the token on the service side using the GSS API in the way 
suggested by Kai. However, how can I send the token to the KDC on the client 
side using GSS?

Thanks,

Colm.

On Fri, Jun 17, 2016 at 4:41 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

> It's not a bug. It works that way, the temp value will be there only
> after you have decode/decrypt the part.
>
> Note SGT is used/consumed in app server side, and can be decrypted
> using the server ticket/key. I suggest you try this in the GssAppTest
> codes using the example code I provided in my last email, where you
> should be able to query/extract the authorization data. If you put the
> token in the authorization data, then after decoding it, you could
> extract token from it. I remembered we had defined the AuthzToken type
> for this actually but guess it's not used yet.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Friday, June 17, 2016 7:21 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Thanks Kai and Jiajia!
>
> I'm trying to get access to the authorization data using the Kerby API
> after getting a service ticket:
>
> SgtTicket tkt = tokenClient.requestSgt(krbToken, serverPrinc,
> cCacheFile.getPath());
>
> However the following is null:
>
> tkt.getTicket().getEncPart()
>
> Is this a bug or how else can I parse the ticket to get the
> authorization data?
>
> Colm.
>
> On Thu, Jun 16, 2016 at 1:01 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
> > Thanks Jiajia for the first question!
> >
> > For the second one, since you're using GSS the even lower level,
> > which is more fine, and should be totally doable. Ref. the following doc:
> >
> > https://docs.oracle.com/javase/7/docs/jre/api/security/jgss/spec/com
> > /s un/security/jgss/ExtendedGSSContext.html
> >
> >   GSSContext ctxt = m.createContext(...)
> >   // Establishing the context
> >   if (ctxt instanceof ExtendedGSSContext) {
> >   ExtendedGSSContext ex = (ExtendedGSSContext)ctxt;
> >   try {
> >   Key key = (key)ex.inquireSecContext(
> >   InquireType.KRB5_GET_SESSION_KEY);
> >   // read key info
> >   } catch (GSSException gsse) {
> >   // deal with exception
> >   }
> >   }
> >
> > As you can see after est

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

Your way should work and the codes should be good to be in, though I wish to be 
able to do some little refactoring later.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, June 23, 2016 6:39 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

On Wed, Jun 22, 2016 at 3:11 PM, Zheng, Kai  wrote:

>
> About AuthzToken type, sorry it's my mistake. I actually meant AdToken 
> and please look at the comment in the class header in AdToken.java. 
> Thanks to Emmanuel, the comment put there is much nice to understand its 
> purpose.
> Basically, when issuing ticket, put a simplified version of the 
> original token (or the token itself for simple for now) into the 
> AdToken wrapper, and then put the AdToken container in the ticket as 
> part of the authorization data.
>

I'm a little confused as to how AdToken should work as compared to the 
AuthorizationData class. Are these duplicate types? In my code, I'm currently 
using AuthorizationData, see TicketIssuer.makeAuthorizationData(...). AdToken 
is not referenced in any other code that I can see. I'm doing something like:

if (kdcRequest.isToken()) {
AuthorizationData authzData = new AuthorizationData();
AuthorizationDataEntry authzDataEntry = new 
AuthorizationDataEntry();
byte[] tokenBytes =

KrbRuntime.getTokenProvider().createTokenEncoder().encodeAsBytes(kdcRequest.getToken());
authzDataEntry.setAuthzData(tokenBytes);
authzDataEntry.setAuthzType(AuthorizationType.NONE);

authzData.setElements(Collections.singletonList(authzDataEntry));
return authzData;
}

Colm.


>
> I don't quite get your 2nd question. I don't find TokenIssuer class in 
> Kerby codebase.
>
> >> I can extract the token on the service side using the GSS API in 
> >> the
> way suggested by Kai.
> I thought this is a major progress. This means you almost make all the 
> thing together.
>
> >>However, how can I send the token to the KDC on the client side 
> >>using
> GSS?
> Great question. Here what you need would be a login module using 
> token, and the module will send the token to KDC for a TGT to get a 
> SGT that's to be used in a GSS session. We have already the module, 
> please look at TokenAuthLoginModule.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, June 22, 2016 9:36 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Hi all,
>
> Some more questions on this task:
>
> 1) Kai, you mentioned the AuthzToken type. Is this defined somewhere 
> so that I can add it in to the AuthorizationType class?
>
> 2) Currently, the TokenIssuer class asks the IdentityService for the 
> authorization data. However, the IdentityService doesn't have access 
> to the token. Is it reasonable default behaviour to insert the 
> received token in the TokenIssuer as the authorization data, and if 
> none exists fall back to ask the IdentityService for any authorization data?
>
> 3) I can extract the token on the service side using the GSS API in 
> the way suggested by Kai. However, how can I send the token to the KDC 
> on the client side using GSS?
>
> Thanks,
>
> Colm.
>
> On Fri, Jun 17, 2016 at 4:41 PM, Zheng, Kai  wrote:
>
> > It's not a bug. It works that way, the temp value will be there only 
> > after you have decode/decrypt the part.
> >
> > Note SGT is used/consumed in app server side, and can be decrypted 
> > using the server ticket/key. I suggest you try this in the 
> > GssAppTest codes using the example code I provided in my last email, 
> > where you should be able to query/extract the authorization data. If 
> > you put the token in the authorization data, then after decoding it, 
> > you could extract token from it. I remembered we had defined the 
> > AuthzToken type for this actually but guess it's not used yet.
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Friday, June 17, 2016 7:21 PM
> > To: kerby@directory.apache.org
> > Subject: Re: JWT pre-authentication - get JWT token on service side
> >
> > Thanks Kai and Jiajia!
> >
> > I'm trying to get access to the authorization data using the Kerby 
> > API after getting a service ticket:
> >
> > SgtTicket tkt = tokenClient.requestSgt(krbToken, serverPrinc, 
> > cCacheFile.getPath

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

This codes are from Gerard and Richard I guess, and we seemed to discuss about 
this sometime before. It looks like a short term work around in the way.

I thought the simple fix could be, if it’s against a token using the token 
mechanism, then just put the AdToken as the authorization data, otherwise if 
any authorization data from identity service, then we use it. Hope this change 
makes everybody happy?

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, June 22, 2016 11:31 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi Kai,

On Wed, Jun 22, 2016 at 3:11 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
I don't quite get your 2nd question. I don't find TokenIssuer class in Kerby 
codebase.

Apologies, I meant "TicketIssuer". It asks the IdentifyService for the 
authorization data:

 getKdcContext().getIdentityService()
.getIdentityAuthorizationData(kdcRequest, encTicketPart);
However, I don't have access to the token in the identity service as I said...
Colm.


>> I can extract the token on the service side using the GSS API in the way 
>> suggested by Kai.
I thought this is a major progress. This means you almost make all the thing 
together.

>>However, how can I send the token to the KDC on the client side using GSS?
Great question. Here what you need would be a login module using token, and the 
module will send the token to KDC for a TGT to get a SGT that's to be used in a 
GSS session. We have already the module, please look at TokenAuthLoginModule.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Wednesday, June 22, 2016 9:36 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi all,

Some more questions on this task:

1) Kai, you mentioned the AuthzToken type. Is this defined somewhere so that I 
can add it in to the AuthorizationType class?

2) Currently, the TokenIssuer class asks the IdentityService for the 
authorization data. However, the IdentityService doesn't have access to the 
token. Is it reasonable default behaviour to insert the received token in the 
TokenIssuer as the authorization data, and if none exists fall back to ask the 
IdentityService for any authorization data?

3) I can extract the token on the service side using the GSS API in the way 
suggested by Kai. However, how can I send the token to the KDC on the client 
side using GSS?

Thanks,

Colm.

On Fri, Jun 17, 2016 at 4:41 PM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:

> It's not a bug. It works that way, the temp value will be there only
> after you have decode/decrypt the part.
>
> Note SGT is used/consumed in app server side, and can be decrypted
> using the server ticket/key. I suggest you try this in the GssAppTest
> codes using the example code I provided in my last email, where you
> should be able to query/extract the authorization data. If you put the
> token in the authorization data, then after decoding it, you could
> extract token from it. I remembered we had defined the AuthzToken type
> for this actually but guess it's not used yet.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Friday, June 17, 2016 7:21 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Thanks Kai and Jiajia!
>
> I'm trying to get access to the authorization data using the Kerby API
> after getting a service ticket:
>
> SgtTicket tkt = tokenClient.requestSgt(krbToken, serverPrinc,
> cCacheFile.getPath());
>
> However the following is null:
>
> tkt.getTicket().getEncPart()
>
> Is this a bug or how else can I parse the ticket to get the
> authorization data?
>
> Colm.
>
> On Thu, Jun 16, 2016 at 1:01 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
> > Thanks Jiajia for the first question!
> >
> > For the second one, since you're using GSS the even lower level,
> > which is more fine, and should be totally doable. Ref. the following doc:
> >
> > https://docs.oracle.com/javase/7/docs/jre/api/security/jgss/spec/com
> > /s un/security/jgss/ExtendedGSSContext.html
> >
> >   GSSContext ctxt = m.createContext(...)
> >   // Establishing the context
> >   if (ctxt instanceof ExtendedGSSContext) {
> >   ExtendedGSSContext ex = (ExtendedGSSContext)ctxt;
> >   try {
> >   Key key = (key)ex.inquir

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

Happy to see your great progress on this hard taking!

About AuthzToken type, sorry it's my mistake. I actually meant AdToken and 
please look at the comment in the class header in AdToken.java. Thanks to 
Emmanuel, the comment put there is much nice to understand its purpose. 
Basically, when issuing ticket, put a simplified version of the original token 
(or the token itself for simple for now) into the AdToken wrapper, and then put 
the AdToken container in the ticket as part of the authorization data.

I don't quite get your 2nd question. I don't find TokenIssuer class in Kerby 
codebase. 

>> I can extract the token on the service side using the GSS API in the way 
>> suggested by Kai. 
I thought this is a major progress. This means you almost make all the thing 
together.

>>However, how can I send the token to the KDC on the client side using GSS?
Great question. Here what you need would be a login module using token, and the 
module will send the token to KDC for a TGT to get a SGT that's to be used in a 
GSS session. We have already the module, please look at TokenAuthLoginModule. 

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, June 22, 2016 9:36 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Hi all,

Some more questions on this task:

1) Kai, you mentioned the AuthzToken type. Is this defined somewhere so that I 
can add it in to the AuthorizationType class?

2) Currently, the TokenIssuer class asks the IdentityService for the 
authorization data. However, the IdentityService doesn't have access to the 
token. Is it reasonable default behaviour to insert the received token in the 
TokenIssuer as the authorization data, and if none exists fall back to ask the 
IdentityService for any authorization data?

3) I can extract the token on the service side using the GSS API in the way 
suggested by Kai. However, how can I send the token to the KDC on the client 
side using GSS?

Thanks,

Colm.

On Fri, Jun 17, 2016 at 4:41 PM, Zheng, Kai  wrote:

> It's not a bug. It works that way, the temp value will be there only 
> after you have decode/decrypt the part.
>
> Note SGT is used/consumed in app server side, and can be decrypted 
> using the server ticket/key. I suggest you try this in the GssAppTest 
> codes using the example code I provided in my last email, where you 
> should be able to query/extract the authorization data. If you put the 
> token in the authorization data, then after decoding it, you could 
> extract token from it. I remembered we had defined the AuthzToken type 
> for this actually but guess it's not used yet.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Friday, June 17, 2016 7:21 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Thanks Kai and Jiajia!
>
> I'm trying to get access to the authorization data using the Kerby API 
> after getting a service ticket:
>
> SgtTicket tkt = tokenClient.requestSgt(krbToken, serverPrinc, 
> cCacheFile.getPath());
>
> However the following is null:
>
> tkt.getTicket().getEncPart()
>
> Is this a bug or how else can I parse the ticket to get the 
> authorization data?
>
> Colm.
>
> On Thu, Jun 16, 2016 at 1:01 PM, Zheng, Kai  wrote:
>
> > Thanks Jiajia for the first question!
> >
> > For the second one, since you're using GSS the even lower level, 
> > which is more fine, and should be totally doable. Ref. the following doc:
> >
> > https://docs.oracle.com/javase/7/docs/jre/api/security/jgss/spec/com
> > /s un/security/jgss/ExtendedGSSContext.html
> >
> >   GSSContext ctxt = m.createContext(...)
> >   // Establishing the context
> >   if (ctxt instanceof ExtendedGSSContext) {
> >   ExtendedGSSContext ex = (ExtendedGSSContext)ctxt;
> >   try {
> >   Key key = (key)ex.inquireSecContext(
> >   InquireType.KRB5_GET_SESSION_KEY);
> >   // read key info
> >   } catch (GSSException gsse) {
> >   // deal with exception
> >   }
> >   }
> >
> > As you can see after established the GSS context, you can query the 
> > SESSION_KEY from the layer. You can also query AUTHZ_DATA field
> similarly!
> > After you get authz data, it's up to you to decode it, say using 
> > Kerby library to decode the ASN1 object and extract any info in it 
> > like the
> token.
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> 

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

It's not a bug. It works that way, the temp value will be there only after you 
have decode/decrypt the part.

Note SGT is used/consumed in app server side, and can be decrypted using the 
server ticket/key. I suggest you try this in the GssAppTest codes using the 
example code I provided in my last email, where you should be able to 
query/extract the authorization data. If you put the token in the authorization 
data, then after decoding it, you could extract token from it. I remembered we 
had defined the AuthzToken type for this actually but guess it's not used yet.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Friday, June 17, 2016 7:21 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Thanks Kai and Jiajia!

I'm trying to get access to the authorization data using the Kerby API after 
getting a service ticket:

SgtTicket tkt = tokenClient.requestSgt(krbToken, serverPrinc, 
cCacheFile.getPath());

However the following is null:

tkt.getTicket().getEncPart()

Is this a bug or how else can I parse the ticket to get the authorization data?

Colm.

On Thu, Jun 16, 2016 at 1:01 PM, Zheng, Kai  wrote:

> Thanks Jiajia for the first question!
>
> For the second one, since you're using GSS the even lower level, which 
> is more fine, and should be totally doable. Ref. the following doc:
>
> https://docs.oracle.com/javase/7/docs/jre/api/security/jgss/spec/com/s
> un/security/jgss/ExtendedGSSContext.html
>
>   GSSContext ctxt = m.createContext(...)
>   // Establishing the context
>   if (ctxt instanceof ExtendedGSSContext) {
>   ExtendedGSSContext ex = (ExtendedGSSContext)ctxt;
>   try {
>   Key key = (key)ex.inquireSecContext(
>   InquireType.KRB5_GET_SESSION_KEY);
>   // read key info
>   } catch (GSSException gsse) {
>   // deal with exception
>   }
>   }
>
> As you can see after established the GSS context, you can query the 
> SESSION_KEY from the layer. You can also query AUTHZ_DATA field similarly!
> After you get authz data, it's up to you to decode it, say using Kerby 
> library to decode the ASN1 object and extract any info in it like the token.
>
> Regards,
> Kai
>
> -Original Message-
> From: Li, Jiajia [mailto:jiajia...@intel.com]
> Sent: Thursday, June 16, 2016 7:50 PM
> To: kerby@directory.apache.org; cohei...@apache.org
> Subject: RE: JWT pre-authentication - get JWT token on service side
>
> Hi Colm,
>
> For the first question: I think now the token has not been put into 
> the issued service ticket as authorization data. You can look at 
> issueTicket()#TgsRequest.java in server side for detail.
>
> Regards,
> Jiajia
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, June 16, 2016 7:19 PM
> To: kerby@directory.apache.org
> Subject: Re: JWT pre-authentication - get JWT token on service side
>
> Thanks Kai. A few questions below.
>
> On Thu, Jun 16, 2016 at 11:33 AM, Zheng, Kai  wrote:
>
> >
> > 1. For issuing service ticket, the token used to do the 
> > authentication or a token derivation was put into the issued service 
> > ticket as authorization data. I'm not sure in current Kerby impl, it 
> > has done this or not. If not, it should be not difficult to support 
> > it, considering we have some Kerby authorization support now.
> >
>
> I can take a look at this. Can you give me some pointers in the code 
> so that I know where to start?
>
>
> >
> > 2. In application server side, it should be able to query and 
> > extract out the token encapsulated in the authorization data field 
> > in the service ticket. This should be doable now, because a proposal 
> > from me quite some ago had already been accepted by Oracle Java, as 
> > recorded in the following ticket, though I hadn't got the chance to 
> > verify it using latest JDK update like JDK8.
> >
> > JDK-8044085, our extension proposal accepted and committed: allowing 
> > querying authorization data field of service ticket.
> > https://bugs.openjdk.java.net/browse/JDK-8044085
>
>
> The JDK service ticket only refers to SASL. If I'm just using GSS on 
> the service side, is it already supported? If so, how can I extract it?
>
> Colm.
>
>
> >
> >
> > So in summary, if you want to try this, I would suggest please go 
> > ahead since it's doable now. Please let me know if you have other
> questions.
> >
> > Regards,
> > Kai
> >
> > -Original Message-

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Thanks Jiajia for the first question!

For the second one, since you're using GSS the even lower level, which is more 
fine, and should be totally doable. Ref. the following doc:
https://docs.oracle.com/javase/7/docs/jre/api/security/jgss/spec/com/sun/security/jgss/ExtendedGSSContext.html

  GSSContext ctxt = m.createContext(...)
  // Establishing the context
  if (ctxt instanceof ExtendedGSSContext) {
  ExtendedGSSContext ex = (ExtendedGSSContext)ctxt;
  try {
  Key key = (key)ex.inquireSecContext(
  InquireType.KRB5_GET_SESSION_KEY);
  // read key info
  } catch (GSSException gsse) {
  // deal with exception
  }
  }

As you can see after established the GSS context, you can query the SESSION_KEY 
from the layer. You can also query AUTHZ_DATA field similarly! After you get 
authz data, it's up to you to decode it, say using Kerby library to decode the 
ASN1 object and extract any info in it like the token. 

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Thursday, June 16, 2016 7:50 PM
To: kerby@directory.apache.org; cohei...@apache.org
Subject: RE: JWT pre-authentication - get JWT token on service side

Hi Colm,

For the first question: I think now the token has not been put into the issued 
service ticket as authorization data. You can look at 
issueTicket()#TgsRequest.java in server side for detail.

Regards,
Jiajia

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, June 16, 2016 7:19 PM
To: kerby@directory.apache.org
Subject: Re: JWT pre-authentication - get JWT token on service side

Thanks Kai. A few questions below.

On Thu, Jun 16, 2016 at 11:33 AM, Zheng, Kai  wrote:

>
> 1. For issuing service ticket, the token used to do the authentication 
> or a token derivation was put into the issued service ticket as 
> authorization data. I'm not sure in current Kerby impl, it has done 
> this or not. If not, it should be not difficult to support it, 
> considering we have some Kerby authorization support now.
>

I can take a look at this. Can you give me some pointers in the code so that I 
know where to start?


>
> 2. In application server side, it should be able to query and extract 
> out the token encapsulated in the authorization data field in the 
> service ticket. This should be doable now, because a proposal from me 
> quite some ago had already been accepted by Oracle Java, as recorded 
> in the following ticket, though I hadn't got the chance to verify it 
> using latest JDK update like JDK8.
>
> JDK-8044085, our extension proposal accepted and committed: allowing 
> querying authorization data field of service ticket.
> https://bugs.openjdk.java.net/browse/JDK-8044085


The JDK service ticket only refers to SASL. If I'm just using GSS on the 
service side, is it already supported? If so, how can I extract it?

Colm.


>
>
> So in summary, if you want to try this, I would suggest please go 
> ahead since it's doable now. Please let me know if you have other questions.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, June 16, 2016 5:54 PM
> To: kerby@directory.apache.org
> Subject: JWT pre-authentication - get JWT token on service side
>
> Hi all,
>
> For the JWT pre-authentication use-case, how can I get access to the 
> token information on the service side?
>
> From the documentation: "The service authenticates the ticket, 
> extracts the token derivation, then enforce any advanced authorization 
> by employing the token derivation and token attributes"
>
> Is there an example in the code to look at?
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Admin privileges in JIRA

[Zheng, Kai]

Yeah, I noticed. Thanks for the work!! Quite agree on the release 
considerations.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, June 16, 2016 5:37 PM
To: Zheng, Kai 
Cc: kerby@directory.apache.org
Subject: Re: Admin privileges in JIRA

Hi Kai,
I don't have any preferences on the release. By all means we can do a 1.0.0 GA 
and move unimplemented features to 1.0.1 or 1.1.0 etc. I'm currently playing 
around with the JWT pre-auth stuff, as you may have noticed, I'd like to finish 
with this before the GA release to fix some remaining bugs.
Colm.

On Thu, Jun 16, 2016 at 10:16 AM, Zheng, Kai 
mailto:kai.zh...@intel.com>> wrote:
Thanks Colm. Do we need to release sooner? Looks like we'll still need quite 
some time to prepare for the features of remote-admin, kpasswd, and GSSAPI 
impl, but I guess they could be pushed to next release like a release after 
1.0.0 GA.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Thursday, June 16, 2016 5:07 PM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: Re: Admin privileges in JIRA

Thanks Stefan. For the record, I've "released" the RC2 version in JIRA.
I've also moved the open issues that were still there for this version to "GA", 
and then closed the released JIRAs.

Colm.

On Wed, Jun 15, 2016 at 9:46 PM, Stefan Seelmann 
mailto:m...@stefan-seelmann.de>>
wrote:

> On 06/15/2016 06:46 PM, Colm O hEigeartaigh wrote:
> > Could someone (Emmanuel?) give me administrator privileges for Kerby
> > in JIRA?
>
> Done.
>
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: JWT pre-authentication - get JWT token on service side

[Zheng, Kai]

Hi Colm,

This was said quite some ago for the long term effort. For that, we need to 
ensure two things:

1. For issuing service ticket, the token used to do the authentication or a 
token derivation was put into the issued service ticket as authorization data. 
I'm not sure in current Kerby impl, it has done this or not. If not, it should 
be not difficult to support it, considering we have some Kerby authorization 
support now.

2. In application server side, it should be able to query and extract out the 
token encapsulated in the authorization data field in the service ticket. This 
should be doable now, because a proposal from me quite some ago had already 
been accepted by Oracle Java, as recorded in the following ticket, though I 
hadn't got the chance to verify it using latest JDK update like JDK8.

JDK-8044085, our extension proposal accepted and committed: allowing querying 
authorization data field of service ticket.
https://bugs.openjdk.java.net/browse/JDK-8044085

So in summary, if you want to try this, I would suggest please go ahead since 
it's doable now. Please let me know if you have other questions. 

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, June 16, 2016 5:54 PM
To: kerby@directory.apache.org
Subject: JWT pre-authentication - get JWT token on service side

Hi all,

For the JWT pre-authentication use-case, how can I get access to the token 
information on the service side?

From the documentation: "The service authenticates the ticket, extracts the 
token derivation, then enforce any advanced authorization by employing the 
token derivation and token attributes"

Is there an example in the code to look at?

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Admin privileges in JIRA

[Zheng, Kai]

Thanks Colm. Do we need to release sooner? Looks like we'll still need quite 
some time to prepare for the features of remote-admin, kpasswd, and GSSAPI 
impl, but I guess they could be pushed to next release like a release after 
1.0.0 GA.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, June 16, 2016 5:07 PM
To: kerby@directory.apache.org
Subject: Re: Admin privileges in JIRA

Thanks Stefan. For the record, I've "released" the RC2 version in JIRA.
I've also moved the open issues that were still there for this version to "GA", 
and then closed the released JIRAs.

Colm.

On Wed, Jun 15, 2016 at 9:46 PM, Stefan Seelmann 
wrote:

> On 06/15/2016 06:46 PM, Colm O hEigeartaigh wrote:
> > Could someone (Emmanuel?) give me administrator privileges for Kerby 
> > in JIRA?
>
> Done.
>
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Kerberos Login fails through Apache Directory Studio

[Zheng, Kai]

I don’t have the experience, but guess you could try different encryption types 
and see if any different result.

And, what JDK are you using?

Regards,
Kai

From: siva venkat [mailto:sivar...@gmail.com]
Sent: Wednesday, June 15, 2016 11:12 PM
To: d...@directory.apache.org; kerby@directory.apache.org
Subject: Kerberos Login fails through Apache Directory Studio

Hi,

I am using latest ApacheDS 
2.0.0-M21 , for Kerberose 
login, I followed all steps mentioned in 
http://directory.apache.org/apacheds/kerberos-ug/4.2-authenticate-studio.html .
I am getting error"javax.security.auth.login.LoginException: Integrity check on 
decrypted field failed (31)" when "Require Pre-Authentication By Encrypted 
TimeStamp" checked.
I am getting error "javax.security.auth.login.LoginException: Checksum Failed" 
when "Require Pre-Authentication By Encrypted TimeStamp" is unchecked.

[cid:ii_iph0izth0_155549b7daf5f5d9]
​
Can you please tell how to fix this issue ?
Seems many other folks facing this issue, see this link 
http://stackoverflow.com/questions/23140518/apacheds-and-kerberos-setup.
Thanks,
Siva

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

Hi Richard,

Thanks a lot for the detailed insightful explanation!!

>> This means that IF tests for NULL needed to be added in various places in 
>> the code.
If the fields are optional, it sounds reasonable to add the IF-NULL test in the 
codes. With the fix, did you see how many cases such tests need to be added? Or 
would you help evaluate how much impact for the change? If its impact is big, 
I’m wondering if we should proceed otherwise. Generally empty value for an 
optional field is convenient for application codes and it won’t affect the real 
byte stream when it’s encoded, so still compatible with other Kerberos vendors. 
I recalled this approach was intentionally used after trying the other option.

It’s a great idea to have the proposed pluggable authorization module and 
thanks a lot for thinking about this aspect!
I thought Jiajia asked a good question, how the authorization data come from? 
Adding the method may allow the backend providers to provide the data in their 
implementation. It should work, on the other hand, it’s not going in the style 
as we did for other aspects. In my understanding, authorization data should be 
composed dynamically according to identity attributes when issuing the tickets. 
The data itself might not be populated into backend previously. Instead, we can 
augment the principal identity to add more fields for authorization 
consideration.

How do you think? Thanks again.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Thursday, May 26, 2016 2:26 AM
To: Apache Directory Developers List 
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

There was a general problem with the ASN.1 decoding code prior to our patch. 
Objects were being created even though the corresponding (optional) tag never 
appeared in the ASN.1 byte stream being decoded. In the case of a SEQUENCE-OF 
an empty container was being created. This did not correctly reflect what was 
present (or not) in the byte stream being decoded. We fixed this so that 
objects are only created when the corresponding tag is actually present in the 
byte stream. This, however, broke some of the handling code. In those cases 
where an optional collection was being processed, previously the collection 
object would be present but have no members. NOW, the collection object itself 
is NULL if the corresponding tag wasn't present in the byte stream. This means 
that IF tests for NULL needed to be added in various places in the code.

Authorization Data is generally site-specific and therefore not inherently a 
part of Kerby. But the Kerberos protocol supports the inclusion, transport, and 
forwarding of authorization data in Kerberos tickets. For example, a Microsoft 
KDC will add authorization data to a ticket which lists the various groups a 
user is a member of (along with other details as well). Ideally Kerby would 
include a plug-able framework in which site implementors would be able to 
include modules which would inject, process, and forward authorization data 
contained in the tickets issued and received by Kerby. For now we have simply 
extended the Backend interface to allow a backend implementation to do the 
authorization data handling. This is not necessarily the ideal place for a 
"generalized" implementation of authorization data handling. However, there is 
likely to be a tight coupling between authorization data handling and the 
backend implementation, so we put this one method in to allow the backend to 
handle the authorization data.

On Wed, May 25, 2016 at 7:41 AM, Gerard Gagliano (JIRA) 
mailto:j...@apache.org>> wrote:

[ 
https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299923#comment-15299923
 ]

Gerard Gagliano commented on DIRKRB-542:




This is related to the Asn1 modifications.  Items were filled in where there 
were none, which is invalid and makes it impossible to re-encode.


It is an abstract class.  You would override it and call the method.  If you 
weren’t wanting Authorization Data, the null is all the rest of the code needs.




> Kerby Authorization
> ---
>
> Key: DIRKRB-542
> URL: https://issues.apache.org/jira/browse/DIRKRB-542
> Project: Directory Kerberos
>  Issue Type: Sub-task
>Reporter: Gerard Gagliano
>Assignee: Gerard Gagliano
> Attachments: ADAll.patch, ad.patch, ad2.patch, ad3.patch, adtest.patch
>
>
> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 4120, 
> 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)



--
Richard M Feezel
rfee...@gmail.com

RE: About Kerby copyright

[Zheng, Kai]

Thanks for the sharing, really interesting ... yeah we're in so different 
conditions. Just back to computer from accompanying my younger boy while his 
mother taking the elder one to a course.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, May 25, 2016 5:01 PM
To: kerby@directory.apache.org
Subject: Re: About Kerby copyright

Le 25/05/16 à 10:41, Zheng, Kai a écrit :
> Yeah, I must learn from you and see how it's well balanced among work, 
> life and open source contribution. :)

Easy : I'm a light sleeper (5:30/6h a night), and I'm married with a wonderful 
wife who sleep 10 hours a night ! That leave me with 4 hours a day at least to 
play with my computer. But this is a battle ! My wife is very jealous and think 
that my computer is my mistress...

Ah, no kid : this helps A LOT (but I'd rather have kids and do less code...)

RE: About Kerby copyright

[Zheng, Kai]

Yeah, I must learn from you and see how it's well balanced among work, life and 
open source contribution. :)

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, May 25, 2016 2:19 PM
To: kerby@directory.apache.org
Subject: Re: About Kerby copyright

Le 25/05/16 à 00:18, Zheng, Kai a écrit :
> Thanks for the nice asking :)
>
> Haox is just a combination of my two boys' given names. 

Nice !!

> I wished it would make some sense to them because in the whole year I spent 
> lots of my spare time on the initial project having to leave them aside some 
> time :( ...

Yeah... Working on an OSS project is VERY demanding, especially because we put 
our soul in it. OTOH, that what make them great ! But familly first !

>
> It's a little pity but I thought Kerby is a perfect name eventually we have. 
> Kerby effort might be slowed down but the wish is still there ...

You now have to have 2 more children, one which givenname starts with Ker and 
the second starting with By ;-)

Thanks a lot for the info, this is very refreshing !

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

It’s pretty cool and my great honor to see you in the conference, Lucas, Shawn 
and Alex!! We talked much and it’s a lot of fun, though we’re not able to meet 
together for a Directory discussion… it’s the pity.

What I understood would be, contribution might be hard and we may earn nothing, 
but at least we can have some friends in the world and talk something when we 
meet. Just ping me when you on board to Shanghai, China, someday in future …

Regards,
Kai

From: Zheng, Kai [mailto:kai.zh...@intel.com]
Sent: Thursday, May 12, 2016 12:17 AM
To: Apache Directory Developers List 
Subject: RE: Travel to Vancouver and Bay Area

I’m also in. Where is 1230p? Is it in the hotel? Is it possible to have a 
meeting so we might have full time yesterday?

From: Lucas Theisen [mailto:lucasthei...@pastdev.com]
Sent: Wednesday, May 11, 2016 8:48 AM
To: Apache Directory Developers List 
mailto:d...@directory.apache.org>>
Subject: Re: Travel to Vancouver and Bay Area


I'm in.  Where you wanna meet?
On May 11, 2016 8:35 AM, "Shawn McKinney" 
mailto:smckin...@apache.org>> wrote:
I am onsite now.  Lunch @ 1230p today?

Shawn

> On May 9, 2016, at 10:36 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
> Sorry I missed this today. Alex I will try to find you on the following days 
> if you’re still there.
>
> Regards,
> Kai
>
> From: akaras...@gmail.com<mailto:akaras...@gmail.com> 
> [mailto:akaras...@gmail.com<mailto:akaras...@gmail.com>] On Behalf Of Alex 
> Karasulu
> Sent: Monday, May 09, 2016 10:39 AM
> To: Apache Directory Developers List 
> mailto:d...@directory.apache.org>>
> Subject: Re: Travel to Vancouver and Bay Area
>
> I'm here if any one from directory wants to connect. Chilling by the 
> escalator for the next couple hours on 2nd floor.
>
> Cheers,
> Alex
>
> On Mon, May 9, 2016 at 9:24 AM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
> Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
> meetup on Thursday?
>
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Monday, May 09, 2016 2:37 AM
> To: Apache Directory Developers List 
> mailto:d...@directory.apache.org>>
> Cc: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Re: Travel to Vancouver and Bay Area
>
> Hi Kai,
>
> I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
> enough people for an Apache Directory meetup ;-)
>
> Colm.
>
>
>
> On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai 
> mailto:kai.zh...@intel.com>> wrote:
>
> > Thanks!! A big pity you won't be there but I guess we could eventually
> > be able to meet elsewhere in future!
> >
> > -Original Message-
> > From: Emmanuel Lécharny 
> > [mailto:elecha...@gmail.com<mailto:elecha...@gmail.com>]
> > Sent: Saturday, May 07, 2016 6:07 AM
> > To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> > Subject: Re: Travel to Vancouver and Bay Area
> >
> > Le 06/05/16 23:41, Zheng, Kai a écrit :
> > > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole
> > > next
> > week I'll be hanging there.
> >
> > Ra... I wish I could have gone :/
> >
> > Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All
> > my best to all of you, guys !
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Best Regards,
> -- Alex

RE: About Kerby copyright

[Zheng, Kai]

Thanks for the nice asking :)

Haox is just a combination of my two boys' given names. I wished it would make 
some sense to them because in the whole year I spent lots of my spare time on 
the initial project having to leave them aside some time :( ...

It's a little pity but I thought Kerby is a perfect name eventually we have. 
Kerby effort might be slowed down but the wish is still there ...

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, May 25, 2016 12:42 AM
To: kerby@directory.apache.org
Subject: Re: About Kerby copyright

Le 24/05/16 à 17:12, Zheng, Kai a écrit :
> Thanks Jiajia for thinking about this. Thanks Emmanuel for the info.
>
> Note, Hoax => Haox. The starting date would be 2015 (at the very beginning).
Just curious : does Haox means something in Chinese ?

Otherwise, where does the name come from ?

thanks !

RE: About Kerby copyright

[Zheng, Kai]

Thanks Jiajia for thinking about this. Thanks Emmanuel for the info.

Note, Hoax => Haox. The starting date would be 2015 (at the very beginning).

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Tuesday, May 24, 2016 5:17 PM
To: kerby@directory.apache.org
Subject: Re: About Kerby copyright

Le 24/05/16 à 10:49, Li, Jiajia a écrit :
> I'm writing the Kerby 
> NOTICE(https://github.com/apache/directory-kerby/blob/trunk/NOTICE.txt).
> I'm not sure of the year of copyright, the NOTICE in ApacheDS is (Copyright 
> 2003-2014), how about Kerby? Can anyone help me?
Starting date is 2014, AFAIR (or 2015?). Basically, this is the date the Hoax 
contribution has been accepted, but this was at the end of 2014 or at the very 
beginning of 2015).

End date is obviously 2016.

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
meetup on Thursday?

Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, May 09, 2016 2:37 AM
To: Apache Directory Developers List 
Cc: kerby@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Hi Kai,

I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
enough people for an Apache Directory meetup ;-)

Colm.



On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai  wrote:

> Thanks!! A big pity you won't be there but I guess we could eventually 
> be able to meet elsewhere in future!
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Saturday, May 07, 2016 6:07 AM
> To: kerby@directory.apache.org
> Subject: Re: Travel to Vancouver and Bay Area
>
> Le 06/05/16 23:41, Zheng, Kai a écrit :
> > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole 
> > next
> week I'll be hanging there.
>
> Ra... I wish I could have gone :/
>
> Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All 
> my best to all of you, guys !
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Thanks!! A big pity you won't be there but I guess we could eventually be able 
to meet elsewhere in future!

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Saturday, May 07, 2016 6:07 AM
To: kerby@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Le 06/05/16 23:41, Zheng, Kai a écrit :
> Hi Shawn, it's great we'll be able to have a meet. Yes, the whole next week 
> I'll be hanging there.

Ra... I wish I could have gone :/

Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All my best 
to all of you, guys !

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Hi Shawn, it's great we'll be able to have a meet. Yes, the whole next week 
I'll be hanging there.

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Saturday, May 07, 2016 5:31 AM
To: Apache Directory Developers List 
Cc: kerby@directory.apache.org; fortr...@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Hello Kai, I will also be in Vancouver next week between Wednesday and Friday 
attending ApacheCon.  If those dates work with your schedule we should try to 
meet.

Thanks,
Shawn

> On May 6, 2016, at 4:22 PM, Zheng, Kai  wrote:
> 
> Hi,
>  
> I will travel to Vancouver (speak about Apache Kerby) and then Bay Area in 
> the next half a month. Is there anybody here happening to be there too so we 
> could meet? If anything I could help with on the Apache Bigdata Conference, 
> please also let me know.
>  
> Regards,
> Kai

Travel to Vancouver and Bay Area

[Zheng, Kai]

Hi,

I will travel to Vancouver (speak about Apache Kerby) and then Bay Area in the 
next half a month. Is there anybody here happening to be there too so we could 
meet? If anything I could help with on the Apache Bigdata Conference, please 
also let me know.

Regards,
Kai

RE: KDC in Java

[Zheng, Kai]

Yes there are already some projects using it. Whether it’s good for your case, 
it depends. Do you have any specifics about your requirement, cluster and the 
related?

Regards,
Kai

From: Jim Shi [mailto:hj...@yahoo.com]
Sent: Tuesday, May 03, 2016 6:26 AM
To: Zheng, Kai ; kerby@directory.apache.org
Subject: Re: KDC in Java

Hi, Kai,
 Thanks for quick reply.
Is that prod ready? Has any one used in actual production?

Jim

On Monday, May 2, 2016 3:18 PM, "Zheng, Kai" 
mailto:kai.zh...@intel.com>> wrote:

Hi Jim,

Yes you're right. But if a Java KDC is the only thing you need, not including 
LDAP things, then you may look at:

https://github.com/apache/directory-kerby or,
http://directory.apache.org/kerby/

Regards,
Kai

-Original Message-
From: Jim Shi [mailto:hj...@yahoo.com.INVALID<mailto:hj...@yahoo.com.INVALID>]
Sent: Tuesday, May 03, 2016 6:11 AM
To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
Subject: KDC in Java

Hi,  we are using MIT KDC server. We would like to replace it with a java 
implementation. I found apacheds-parent-2.0.0-M21 that has a KDC server in it.
Is that the right place to get get started? Is there any doc? Any help is 
appreciated.
Thank you so much
Jim

RE: KDC in Java

[Zheng, Kai]

Hi Jim,

Yes you're right. But if a Java KDC is the only thing you need, not including 
LDAP things, then you may look at:

https://github.com/apache/directory-kerby or,
http://directory.apache.org/kerby/

Regards,
Kai

-Original Message-
From: Jim Shi [mailto:hj...@yahoo.com.INVALID] 
Sent: Tuesday, May 03, 2016 6:11 AM
To: kerby@directory.apache.org
Subject: KDC in Java

Hi,  we are using MIT KDC server. We would like to replace it with a java 
implementation. I found apacheds-parent-2.0.0-M21 that has a KDC server in it.
Is that the right place to get get started? Is there any doc? Any help is 
appreciated.
Thank you so much
Jim

Kerby powered

[Zheng, Kai]

Hi,

How about adding a section in Kerby main site page mentioning projects powered 
by Kerby?

Would anyone like this to mention your project or company? Please comment, 
thanks.

Let me start the list:

1.   Apache Hadoop;

2.   Apache Calcite;

3.   Apache Directory (?)

Regards,
Kai