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 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) <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 > -- Richard M Feezel rfee...@gmail.com
