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:[email protected]] Sent: Thursday, May 26, 2016 12:38 PM To: Apache Directory Developers List <[email protected]> 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.
