directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization
Date Wed, 25 May 2016 23:00:16 GMT
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.


From: Richard Feezel []
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) <<>>


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

Richard M Feezel<>
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message