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

[Zheng, Kai]

I committed it to allow more time to exercise and test. For the backend change, 
I believe we'll need more elegant way like modular/pluggable authorization 
support. We can do that when have more thoughts and experience.

Thanks Gerard and Richard both for the major contribution, filling the gap in 
authorization domain!!

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Friday, May 27, 2016 8:41 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Great discussions, Richard and Emmanuel! I would suggest we accept the change 
and let it run some time doing some tests against MIT kinit/KDC. Anyway the 
behavior can be easily changed back if later found it impacts too big. For the 
authorization data change in backend, I would agree that it's a simple way to 
work. 

+1 on the patch attached in DIRKRB-542. If no other concern I would commit it 
in the weekend. Thanks!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Thursday, May 26, 2016 12:38 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. 
> Thus the correct representation of items that are empty in object 
> space is with NULL, not with a tagged field with no elements.

That's the same thing, IMO :

"The Kerberos protocol does
   not semantically distinguish between an absent optional SEQUENCE OF
   type and a present optional but empty SEQUENCE OF type."

Usinhg Null or an empty list should result in the same behavior, when 
generating the ASN.1 stream.

In ApacheDS Kerbeors implementation, we schoose to create an empty list instead 
of seting the padata field to null if we have no padata. What is important is 
not to transmit the emtpy list in teh ASN.1 stream :


// The PD-DATA if any -
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );

// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );

// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}

The key here was to avoid NPE. Now, you can perfectly avoid to create such an 
empty list, and to check for null when accessing the padata field.

> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary 
> IF test in the patch.
> But these were found based on running tests and seeing NPE's thrown at 
> run time, not on a survey of the code to try to identify all the 
> possible failure points. We didn't feel competent to make such a 
> survey given our limited familiarity with the code structure. I 
> believe the correct way to conduct such a survey would be to go to the 
> IETF specifications and identify all optional fields, then search the 
> code for all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :

KDC_REQ padata

KDC-REQ-BODY additional-tickets

KDC-REP padata


>
> Regarding authorization data: given the open architecture, and 
> vendor-proprietary nature, of authorization data I believe you would 
> have a very difficult time trying to think of all the different back 
> end data elements to include in the principal identity object. I 
> suppose you could include a Map type structure of name value pairs, 
> but I'd be concerned about the amount of effort expended to construct 
> that data in the back end, only to have the majority of it be ignored 
> by the authorization data plugins.
>
> I'm afraid the relationship between back end implementations and 
> authorization data implementations is too close to develop an 
> efficient generalized API between them that would meet the needs of 
> all vendors. I believe any generalized API between back end 
> implementations and authorization data handlers MUST support arbitrary 
> and proprietary communications between these two elements.

Agreed.

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

[Zheng, Kai]

Great discussions, Richard and Emmanuel! I would suggest we accept the change 
and let it run some time doing some tests against MIT kinit/KDC. Anyway the 
behavior can be easily changed back if later found it impacts too big. For the 
authorization data change in backend, I would agree that it's a simple way to 
work. 

+1 on the patch attached in DIRKRB-542. If no other concern I would commit it 
in the weekend. Thanks!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, May 26, 2016 12:38 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. 
> Thus the correct representation of items that are empty in object 
> space is with NULL, not with a tagged field with no elements.

That's the same thing, IMO :

"The Kerberos protocol does
   not semantically distinguish between an absent optional SEQUENCE OF
   type and a present optional but empty SEQUENCE OF type."

Usinhg Null or an empty list should result in the same behavior, when 
generating the ASN.1 stream.

In ApacheDS Kerbeors implementation, we schoose to create an empty list instead 
of seting the padata field to null if we have no padata. What is important is 
not to transmit the emtpy list in teh ASN.1 stream :


// The PD-DATA if any -
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );

// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );

// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}

The key here was to avoid NPE. Now, you can perfectly avoid to create such an 
empty list, and to check for null when accessing the padata field.

> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary 
> IF test in the patch.
> But these were found based on running tests and seeing NPE's thrown at 
> run time, not on a survey of the code to try to identify all the 
> possible failure points. We didn't feel competent to make such a 
> survey given our limited familiarity with the code structure. I 
> believe the correct way to conduct such a survey would be to go to the 
> IETF specifications and identify all optional fields, then search the 
> code for all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :

KDC_REQ padata

KDC-REQ-BODY additional-tickets

KDC-REP padata


>
> Regarding authorization data: given the open architecture, and 
> vendor-proprietary nature, of authorization data I believe you would 
> have a very difficult time trying to think of all the different back 
> end data elements to include in the principal identity object. I 
> suppose you could include a Map type structure of name value pairs, 
> but I'd be concerned about the amount of effort expended to construct 
> that data in the back end, only to have the majority of it be ignored 
> by the authorization data plugins.
>
> I'm afraid the relationship between back end implementations and 
> authorization data implementations is too close to develop an 
> efficient generalized API between them that would meet the needs of 
> all vendors. I believe any generalized API between back end 
> implementations and authorization data handlers MUST support arbitrary 
> and proprietary communications between these two elements.

Agreed.

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

[Emmanuel Lécharny]

Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. Thus
> the correct representation of items that are empty in object space is with
> NULL, not with a tagged field with no elements. 

That's the same thing, IMO :

"The Kerberos protocol does
   not semantically distinguish between an absent optional SEQUENCE OF
   type and a present optional but empty SEQUENCE OF type."

Usinhg Null or an empty list should result in the same behavior, when 
generating the ASN.1 stream.

In ApacheDS Kerbeors implementation, we schoose to create an empty list instead 
of seting the padata field to null if we have no padata. What is important is 
not to transmit the emtpy list in teh ASN.1 stream :


// The PD-DATA if any -
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );

// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );

// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}

The key here was to avoid NPE. Now, you can perfectly avoid to create such an 
empty list, and to check for null when accessing the padata field.

> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary IF
> test in the patch. 
> But these were found based on running tests and seeing
> NPE's thrown at run time, not on a survey of the code to try to identify
> all the possible failure points. We didn't feel competent to make such a
> survey given our limited familiarity with the code structure. I believe the
> correct way to conduct such a survey would be to go to the IETF
> specifications and identify all optional fields, then search the code for
> all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :

KDC_REQ padata

KDC-REQ-BODY additional-tickets

KDC-REP padata


>
> Regarding authorization data: given the open architecture, and
> vendor-proprietary nature, of authorization data I believe you would have a
> very difficult time trying to think of all the different back end data
> elements to include in the principal identity object. I suppose you could
> include a Map type structure of name value pairs, but I'd be concerned
> about the amount of effort expended to construct that data in the back end,
> only to have the majority of it be ignored by the authorization data
> plugins.
>
> I'm afraid the relationship between back end implementations and
> authorization data implementations is too close to develop an efficient
> generalized API between them that would meet the needs of all vendors. I
> believe any generalized API between back end implementations and
> authorization data handlers MUST support arbitrary and proprietary
> communications between these two elements.

Agreed.

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

[Richard Feezel]

Kai,

I recall that the Kerberos specifications indicate that empty lists
(sequences) should not be included in the ASN.1 encoded byte stream. Thus
the correct representation of items that are empty in object space is with
NULL, not with a tagged field with no elements. We didn't run into very
many cases, though when we did we fixed them by adding the necessary IF
test in the patch. But these were found based on running tests and seeing
NPE's thrown at run time, not on a survey of the code to try to identify
all the possible failure points. We didn't feel competent to make such a
survey given our limited familiarity with the code structure. I believe the
correct way to conduct such a survey would be to go to the IETF
specifications and identify all optional fields, then search the code for
all references to the objects corresponding to these fields.

Regarding authorization data: given the open architecture, and
vendor-proprietary nature, of authorization data I believe you would have a
very difficult time trying to think of all the different back end data
elements to include in the principal identity object. I suppose you could
include a Map type structure of name value pairs, but I'd be concerned
about the amount of effort expended to construct that data in the back end,
only to have the majority of it be ignored by the authorization data
plugins.

I'm afraid the relationship between back end implementations and
authorization data implementations is too close to develop an efficient
generalized API between them that would meet the needs of all vendors. I
believe any generalized API between back end implementations and
authorization data handlers MUST support arbitrary and proprietary
communications between these two elements.

One approach to achieving this communication would be to have the reference
to the back end implementation available to the authorization data plugins.
The plugins could then cast the reference to a proprietary sub-class, or
interface, and access supporting methods.

We included the authorization data handling in the back end API as a
simplification in recognition of this tight coupling between back end data
and the handling of authorization data.

Also note that an authorization data plugin framework should probably
support multiple plugins in a chain so that "standard" processing doesn't
have to be copied into each new plugin. The Kerberos specifications do
define some guidelines for the copying of authorization data from a TGT to
a service ticket, for instance.

On Wed, May 25, 2016 at 7:00 PM, Zheng, Kai <kai.zh...@intel.com> wrote:

> 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 <dev@directory.apache.org>
> *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 t

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

[Richard Feezel]

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) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

>> You can run "git checkout 3ba4a47f29d16ad2416b9e999ed9927f40390c66" to be 
>> that early version.
Please do this separately in a new working copy or workspace, to avoid loss of 
your local changes.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Tuesday, April 05, 2016 9:47 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Cc: ke...@directory.apache.org
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Hi Gerard,
I think this commit 
"https://github.com/apache/directory-kerby/commit/3ba4a47f29d16ad2416b9e999ed9927f40390c66;
 is what Kai said.

You can run "git checkout 3ba4a47f29d16ad2416b9e999ed9927f40390c66" to be that 
early version.

Regards,
Jiajia

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 9:14 AM
To: Apache Directory Developers List
Cc: ke...@directory.apache.org
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

That sounds good.  Could you be specifiec what version to get.  If not can you 
give some guidance about what to look for?

Regards,
g

--

> On Apr 4, 2016, at 5:11 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
> I forgot to mention that, you can check out the very early version of Kerby 
> codebase, where it contains a kerb codec test module originated from 
> JaasLounge library. Starting with it, may make your life easier.
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Zheng, Kai [mailto:kai.zh...@intel.com] 
> Sent: Tuesday, April 05, 2016 7:05 AM
> To: Apache Directory Developers List <dev@directory.apache.org>; 
> ke...@directory.apache.org
> Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Thanks for the sync up Gerard!
> 
> We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
> change may need to take some time to be mature. Anyway it sounds good that 
> you and Richard are working on the refinement. Thanks!
> 
> I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
> it by rebasing it to Kerby.
> http://jaaslounge.sourceforge.net/
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Gerard Gagliano [mailto:gera...@prodentity.com] 
> Sent: Tuesday, April 05, 2016 6:55 AM
> To: Apache Directory Developers List <dev@directory.apache.org>
> Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Kai,
> 
> We are thinking about some additional stuff, but this is all we have done 
> thus far.
> 
> As for tests, Richard is putting some together.  What time frame are you 
> thinking for RC3?
> 
> Also, are you aware of any Java code that can parse MS-PAC?
> 
> Thanks!
> 
> g
> 
> --
>> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>>  ] 
>> 
>> Kai Zheng commented on DIRKRB-542:
>> --
>> 
>> Is there any update? It can be a major thing for the next RC release. Thanks.
>> 
>>> 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: ad.patch, ad2.patch, ad3.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)
> 

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

[Li, Jiajia]

Hi Gerard,
I think this commit 
"https://github.com/apache/directory-kerby/commit/3ba4a47f29d16ad2416b9e999ed9927f40390c66;
 is what Kai said.

You can run "git checkout 3ba4a47f29d16ad2416b9e999ed9927f40390c66" to be that 
early version.

Regards,
Jiajia

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 9:14 AM
To: Apache Directory Developers List
Cc: ke...@directory.apache.org
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

That sounds good.  Could you be specifiec what version to get.  If not can you 
give some guidance about what to look for?

Regards,
g

--

> On Apr 4, 2016, at 5:11 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
> I forgot to mention that, you can check out the very early version of Kerby 
> codebase, where it contains a kerb codec test module originated from 
> JaasLounge library. Starting with it, may make your life easier.
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Zheng, Kai [mailto:kai.zh...@intel.com] 
> Sent: Tuesday, April 05, 2016 7:05 AM
> To: Apache Directory Developers List <dev@directory.apache.org>; 
> ke...@directory.apache.org
> Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Thanks for the sync up Gerard!
> 
> We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
> change may need to take some time to be mature. Anyway it sounds good that 
> you and Richard are working on the refinement. Thanks!
> 
> I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
> it by rebasing it to Kerby.
> http://jaaslounge.sourceforge.net/
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Gerard Gagliano [mailto:gera...@prodentity.com] 
> Sent: Tuesday, April 05, 2016 6:55 AM
> To: Apache Directory Developers List <dev@directory.apache.org>
> Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Kai,
> 
> We are thinking about some additional stuff, but this is all we have done 
> thus far.
> 
> As for tests, Richard is putting some together.  What time frame are you 
> thinking for RC3?
> 
> Also, are you aware of any Java code that can parse MS-PAC?
> 
> Thanks!
> 
> g
> 
> --
>> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>>  ] 
>> 
>> Kai Zheng commented on DIRKRB-542:
>> --
>> 
>> Is there any update? It can be a major thing for the next RC release. Thanks.
>> 
>>> 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: ad.patch, ad2.patch, ad3.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)
> 

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

[Gerard Gagliano]

Kai,

That sounds good.  Could you be specifiec what version to get.  If not can you 
give some guidance about what to look for?

Regards,
g

--

> On Apr 4, 2016, at 5:11 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
> I forgot to mention that, you can check out the very early version of Kerby 
> codebase, where it contains a kerb codec test module originated from 
> JaasLounge library. Starting with it, may make your life easier.
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Zheng, Kai [mailto:kai.zh...@intel.com] 
> Sent: Tuesday, April 05, 2016 7:05 AM
> To: Apache Directory Developers List <dev@directory.apache.org>; 
> ke...@directory.apache.org
> Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Thanks for the sync up Gerard!
> 
> We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
> change may need to take some time to be mature. Anyway it sounds good that 
> you and Richard are working on the refinement. Thanks!
> 
> I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
> it by rebasing it to Kerby.
> http://jaaslounge.sourceforge.net/
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Gerard Gagliano [mailto:gera...@prodentity.com] 
> Sent: Tuesday, April 05, 2016 6:55 AM
> To: Apache Directory Developers List <dev@directory.apache.org>
> Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Kai,
> 
> We are thinking about some additional stuff, but this is all we have done 
> thus far.
> 
> As for tests, Richard is putting some together.  What time frame are you 
> thinking for RC3?
> 
> Also, are you aware of any Java code that can parse MS-PAC?
> 
> Thanks!
> 
> g
> 
> --
>> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>>  ] 
>> 
>> Kai Zheng commented on DIRKRB-542:
>> --
>> 
>> Is there any update? It can be a major thing for the next RC release. Thanks.
>> 
>>> 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: ad.patch, ad2.patch, ad3.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)
> 

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

[Zheng, Kai]

I forgot to mention that, you can check out the very early version of Kerby 
codebase, where it contains a kerb codec test module originated from JaasLounge 
library. Starting with it, may make your life easier.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Tuesday, April 05, 2016 7:05 AM
To: Apache Directory Developers List <dev@directory.apache.org>; 
ke...@directory.apache.org
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Thanks for the sync up Gerard!

We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
change may need to take some time to be mature. Anyway it sounds good that you 
and Richard are working on the refinement. Thanks!

I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
it by rebasing it to Kerby.
http://jaaslounge.sourceforge.net/

Regards,
Kai

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 6:55 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

We are thinking about some additional stuff, but this is all we have done thus 
far.

As for tests, Richard is putting some together.  What time frame are you 
thinking for RC3?

Also, are you aware of any Java code that can parse MS-PAC?

Thanks!

g

--
> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>  ] 
> 
> Kai Zheng commented on DIRKRB-542:
> --
> 
> Is there any update? It can be a major thing for the next RC release. Thanks.
> 
>> 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: ad.patch, ad2.patch, ad3.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)

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

[Zheng, Kai]

Thanks for the sync up Gerard!

We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
change may need to take some time to be mature. Anyway it sounds good that you 
and Richard are working on the refinement. Thanks!

I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
it by rebasing it to Kerby.
http://jaaslounge.sourceforge.net/

Regards,
Kai

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 6:55 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

We are thinking about some additional stuff, but this is all we have done thus 
far.

As for tests, Richard is putting some together.  What time frame are you 
thinking for RC3?

Also, are you aware of any Java code that can parse MS-PAC?

Thanks!

g

--
> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>  ] 
> 
> Kai Zheng commented on DIRKRB-542:
> --
> 
> Is there any update? It can be a major thing for the next RC release. Thanks.
> 
>> 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: ad.patch, ad2.patch, ad3.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)

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

[Gerard Gagliano]

Kai,

We are thinking about some additional stuff, but this is all we have done thus 
far.

As for tests, Richard is putting some together.  What time frame are you 
thinking for RC3?

Also, are you aware of any Java code that can parse MS-PAC?

Thanks!

g

--
> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>  ] 
> 
> Kai Zheng commented on DIRKRB-542:
> --
> 
> Is there any update? It can be a major thing for the next RC release. Thanks.
> 
>> 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: ad.patch, ad2.patch, ad3.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)

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

[Li, Jiajia]

Thanks Richard and Gerard for the quick changes, I will test the new patch soon.

Regards,
Jiajia

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Thursday, March 31, 2016 7:50 PM
To: Apache Directory Developers List
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

I have completed a set of changes which addresses the induced problem in 
Asn1CollectionType. I have also made changes to the tests where the test was 
dependent on the incorrect behavior of this class. I have all tests passing now.

Gerard should be able to post an additional patch with these changes today.

On Thu, Mar 31, 2016 at 6:20 AM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Thanks Richard for digging into the deep!

If the test failure is the only issue incurred by the desired change, we can 
fix the test anyway. But I’m afraid the impact may be more than that. I 
remembered I had considered to change the behavior, but due to some impacts I 
leave it as it was.

When the patch can compile and have the basic issues resolved, I would look at 
the change and see how to fix the failure.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com<mailto:rfee...@gmail.com>]
Sent: Thursday, March 31, 2016 11:51 AM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

PersonnelRecordTest is indeed failing due to changes in Asn1CollectionType.java 
in the patch. Unfortunately we can't simply roll back the changes because the 
changes were made to address a problem with the decoding logic which resulted 
in adding default or empty values to the decoded object when fields were 
missing in the encoded data stream. This is incorrect behavior. Additional 
changes will be necessary to this class to correct the induced problem.

On Wed, Mar 30, 2016 at 9:44 PM, Jiajia Li (JIRA) 
<j...@apache.org<mailto:j...@apache.org>> wrote:

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

Jiajia Li commented on DIRKRB-542:
--

[~gg], thanks for your contribution, I think it will be new achievement for 
Kerby.
Some issues:
1. After applying the patch to trunk, with some tests 
failure(PersonnelRecordTest, SignedDataTest...)
2. Compilation failure(ADAuthenticationIndicators.java)
3. The patch reformatted some original code, then some lines are longer than 80 
characters(ps: Each line should not exceed 80)
4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I think 
some of them can be removed.

> 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: ad.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<mailto:rfee...@gmail.com>



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

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

[Richard Feezel]

I have completed a set of changes which addresses the induced problem in
Asn1CollectionType. I have also made changes to the tests where the test
was dependent on the incorrect behavior of this class. I have all tests
passing now.

Gerard should be able to post an additional patch with these changes today.

On Thu, Mar 31, 2016 at 6:20 AM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Thanks Richard for digging into the deep!
>
>
>
> If the test failure is the only issue incurred by the desired change, we
> can fix the test anyway. But I’m afraid the impact may be more than that. I
> remembered I had considered to change the behavior, but due to some impacts
> I leave it as it was.
>
>
>
> When the patch can compile and have the basic issues resolved, I would
> look at the change and see how to fix the failure.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Richard Feezel [mailto:rfee...@gmail.com]
> *Sent:* Thursday, March 31, 2016 11:51 AM
> *To:* Apache Directory Developers List <dev@directory.apache.org>
> *Subject:* Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization
>
>
>
> PersonnelRecordTest is indeed failing due to changes in
> Asn1CollectionType.java in the patch. Unfortunately we can't simply roll
> back the changes because the changes were made to address a problem with
> the decoding logic which resulted in adding default or empty values to the
> decoded object when fields were missing in the encoded data stream. This is
> incorrect behavior. Additional changes will be necessary to this class to
> correct the induced problem.
>
>
>
> On Wed, Mar 30, 2016 at 9:44 PM, Jiajia Li (JIRA) <j...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
> ]
>
> Jiajia Li commented on DIRKRB-542:
> --
>
> [~gg], thanks for your contribution, I think it will be new achievement
> for Kerby.
> Some issues:
> 1. After applying the patch to trunk, with some tests
> failure(PersonnelRecordTest, SignedDataTest...)
> 2. Compilation failure(ADAuthenticationIndicators.java)
> 3. The patch reformatted some original code, then some lines are longer
> than 80 characters(ps: Each line should not exceed 80)
> 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I
> think some of them can be removed.
>
>
> > 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: ad.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
>



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

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

[Zheng, Kai]

Thanks Richard for digging into the deep!

If the test failure is the only issue incurred by the desired change, we can 
fix the test anyway. But I’m afraid the impact may be more than that. I 
remembered I had considered to change the behavior, but due to some impacts I 
leave it as it was.

When the patch can compile and have the basic issues resolved, I would look at 
the change and see how to fix the failure.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Thursday, March 31, 2016 11:51 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

PersonnelRecordTest is indeed failing due to changes in Asn1CollectionType.java 
in the patch. Unfortunately we can't simply roll back the changes because the 
changes were made to address a problem with the decoding logic which resulted 
in adding default or empty values to the decoded object when fields were 
missing in the encoded data stream. This is incorrect behavior. Additional 
changes will be necessary to this class to correct the induced problem.

On Wed, Mar 30, 2016 at 9:44 PM, Jiajia Li (JIRA) 
<j...@apache.org<mailto:j...@apache.org>> wrote:

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

Jiajia Li commented on DIRKRB-542:
--

[~gg], thanks for your contribution, I think it will be new achievement for 
Kerby.
Some issues:
1. After applying the patch to trunk, with some tests 
failure(PersonnelRecordTest, SignedDataTest...)
2. Compilation failure(ADAuthenticationIndicators.java)
3. The patch reformatted some original code, then some lines are longer than 80 
characters(ps: Each line should not exceed 80)
4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I think 
some of them can be removed.

> 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: ad.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<mailto:rfee...@gmail.com>

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

[Li, Jiajia]

Run “mvn clean package -DskipTests” then with the following Compilation failure:

[ERROR] 
directory-kerby/kerby-kerb/kerb-core/src/main/java/org/apache/kerby/kerberos/kerb/type/ad/ADAuthenticationIndicators.java:[34,9]
 no suitable constructor found for 
AuthorizationDataEntry(org.apache.kerby.asn1.Asn1FieldInfo[],org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry(org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType,byte[])
 is not applicable
[ERROR] (actual argument org.apache.kerby.asn1.Asn1FieldInfo[] cannot be 
converted to org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType by method 
invocation conversion)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry(org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType)
 is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry()
 is not applicable

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

I don't believe ADAuthenticationIndicators, note the S at the end belongs. It 
was renamed to singular.

On Wed, Mar 30, 2016 at 10:17 PM, Gerard Gagliano 
<gera...@prodentity.com<mailto:gera...@prodentity.com>> wrote:
There should not be any compilation issues, can you describe the errors?

--
> On Mar 30, 2016, at 7:44 PM, Jiajia Li (JIRA) 
> <j...@apache.org<mailto:j...@apache.org>> wrote:
>
>
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
>  ]
>
> Jiajia Li commented on DIRKRB-542:
> --
>
> [~gg], thanks for your contribution, I think it will be new achievement for 
> Kerby.
> Some issues:
> 1. After applying the patch to trunk, with some tests 
> failure(PersonnelRecordTest, SignedDataTest...)
> 2. Compilation failure(ADAuthenticationIndicators.java)
> 3. The patch reformatted some original code, then some lines are longer than 
> 80 characters(ps: Each line should not exceed 80)
> 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I 
> think some of them can be removed.
>
>> 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: ad.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<mailto:rfee...@gmail.com>

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

[Richard Feezel]

PersonnelRecordTest is indeed failing due to changes in
Asn1CollectionType.java in the patch. Unfortunately we can't simply roll
back the changes because the changes were made to address a problem with
the decoding logic which resulted in adding default or empty values to the
decoded object when fields were missing in the encoded data stream. This is
incorrect behavior. Additional changes will be necessary to this class to
correct the induced problem.

On Wed, Mar 30, 2016 at 9:44 PM, Jiajia Li (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
> ]
>
> Jiajia Li commented on DIRKRB-542:
> --
>
> [~gg], thanks for your contribution, I think it will be new achievement
> for Kerby.
> Some issues:
> 1. After applying the patch to trunk, with some tests
> failure(PersonnelRecordTest, SignedDataTest...)
> 2. Compilation failure(ADAuthenticationIndicators.java)
> 3. The patch reformatted some original code, then some lines are longer
> than 80 characters(ps: Each line should not exceed 80)
> 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I
> think some of them can be removed.
>
> > 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: ad.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: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Richard Feezel]

I don't believe ADAuthenticationIndicators, note the S at the end belongs.
It was renamed to singular.

On Wed, Mar 30, 2016 at 10:17 PM, Gerard Gagliano 
wrote:

> There should not be any compilation issues, can you describe the errors?
>
> --
> > On Mar 30, 2016, at 7:44 PM, Jiajia Li (JIRA)  wrote:
> >
> >
> >[
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
> ]
> >
> > Jiajia Li commented on DIRKRB-542:
> > --
> >
> > [~gg], thanks for your contribution, I think it will be new achievement
> for Kerby.
> > Some issues:
> > 1. After applying the patch to trunk, with some tests
> failure(PersonnelRecordTest, SignedDataTest...)
> > 2. Compilation failure(ADAuthenticationIndicators.java)
> > 3. The patch reformatted some original code, then some lines are longer
> than 80 characters(ps: Each line should not exceed 80)
> > 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I
> think some of them can be removed.
> >
> >> 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: ad.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: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Gerard Gagliano]

There should not be any compilation issues, can you describe the errors?

--
> On Mar 30, 2016, at 7:44 PM, Jiajia Li (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
>  ] 
> 
> Jiajia Li commented on DIRKRB-542:
> --
> 
> [~gg], thanks for your contribution, I think it will be new achievement for 
> Kerby.
> Some issues:
> 1. After applying the patch to trunk, with some tests 
> failure(PersonnelRecordTest, SignedDataTest...)
> 2. Compilation failure(ADAuthenticationIndicators.java)
> 3. The patch reformatted some original code, then some lines are longer than 
> 80 characters(ps: Each line should not exceed 80)
> 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I 
> think some of them can be removed.
> 
>> 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: ad.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)