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

2016-05-25 Thread 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

2016-05-25 Thread 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  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 
> *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 

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

2016-05-25 Thread 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


[jira] [Commented] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Emmanuel Lecharny (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300327#comment-15300327
 ] 

Emmanuel Lecharny commented on DIRSERVER-2146:
--

Hi Martin,

yes, this is an issue I'm working on presently. I get it fixed in a branch, but 
there are a lot of things that need to be tuned to get it back to trunk. FTR, 
it was a 2 weeks work, with basically a complete rewrite of many classes 
(Value, Ava, Rdn, Dn, Filter, etc)

I don't think that will be available in the next few days.

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
> Attachments: LdapLoginModuleSpecialNamesTestCase.ldif
>
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Created] (DIRKRB-575) SaslAppTest failure due to input having nothing to do with test

2016-05-25 Thread Gerard Gagliano (JIRA)
Gerard Gagliano created DIRKRB-575:
--

 Summary: SaslAppTest failure due to input having nothing to do 
with test
 Key: DIRKRB-575
 URL: https://issues.apache.org/jira/browse/DIRKRB-575
 Project: Directory Kerberos
  Issue Type: Bug
Reporter: Gerard Gagliano
Priority: Trivial


Running the integration-test SaslAppTest results in a failure of the test if 
the host machine (the one running the test) returns a host name of something 
like localhost.localdomain instead of localhost.



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


[jira] [Commented] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1532#comment-1532
 ] 

Martin Choma commented on DIRSERVER-2146:
-

On client side this error occures 

Message ID : 7
Add Request :
Entry
dn[n]: 
uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: Hi
cn: Java Duke
sn: Duke
userpassword: 0x50 0x61 0x73 0x73 0x77 0x6F 0x72 0x64 0x31 
: ERR_268 Cannot find a partition for 
uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
> Attachments: LdapLoginModuleSpecialNamesTestCase.ldif
>
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Commented] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300017#comment-15300017
 ] 

Martin Choma commented on DIRSERVER-2146:
-

We are trying this values based on specification 
https://tools.ietf.org/html/rfc2253#section-5

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
> Attachments: LdapLoginModuleSpecialNamesTestCase.ldif
>
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Updated] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Choma updated DIRSERVER-2146:

Attachment: LdapLoginModuleSpecialNamesTestCase.ldif

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
> Attachments: LdapLoginModuleSpecialNamesTestCase.ldif
>
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Updated] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Choma updated DIRSERVER-2146:

Attachment: (was: LdapLoginModuleSpecialNamesTestCase.ldif)

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Updated] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Choma updated DIRSERVER-2146:

Attachment: LdapLoginModuleSpecialNamesTestCase.ldif

> Using special chars in uid makes problem
> 
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating 
> ldap items with special characters, ApacheDS fails. In version 20 the same 
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: uid=Sue\, Grabbit and 
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
> Adding entry: 
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
> binary
> 14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
> (pool-7-thread-1) The Dn 
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
>  cannot be normalized
> 14:27:43,258 WARN  
> [org.apache.directory.server.core.normalization.NormalizationInterceptor] 
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN  
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already 
> exists in the attribute (uid)



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


[jira] [Created] (DIRSERVER-2146) Using special chars in uid makes problem

2016-05-25 Thread Martin Choma (JIRA)
Martin Choma created DIRSERVER-2146:
---

 Summary: Using special chars in uid makes problem
 Key: DIRSERVER-2146
 URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
 Project: Directory ApacheDS
  Issue Type: Bug
Affects Versions: 2.0.0-M21
Reporter: Martin Choma


I am trying to upgrade from version 20 to 21 and hit problem, when creating 
ldap items with special characters, ApacheDS fails. In version 20 the same 
entries were created seamlessly.

14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: uid=Sue\, Grabbit and 
Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:43,163 WARN  
[org.apache.directory.server.core.normalization.NormalizationInterceptor] 
(pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) 
Adding entry: 
uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] 
(pool-7-thread-1) The 'uid' AttributeType and values must both be String or 
binary
14:27:43,257 WARN  [org.apache.directory.api.ldap.model.entry.DefaultEntry] 
(pool-7-thread-1) The Dn 
'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
 cannot be normalized
14:27:43,258 WARN  
[org.apache.directory.server.core.normalization.NormalizationInterceptor] 
(pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
14:27:43,258 WARN  [org.apache.directory.api.ldap.model.entry.DefaultAttribute] 
(pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already exists 
in the attribute (uid)



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


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

2016-05-25 Thread Gerard Gagliano (JIRA)

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


[jira] [Updated] (DIRKRB-574) Implement a concurrent test to benchmark throughput and latency of kerby KDC

2016-05-25 Thread Kai Zheng (JIRA)

 [ 
https://issues.apache.org/jira/browse/DIRKRB-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kai Zheng updated DIRKRB-574:
-
Description: This would add a concurrent benchmark test to measure the 
throughput and latency of Kerby KDC.  (was: Each perform the kinit main method 
can only start a thread to send socket requests, and can't statistics the 
throughput and delay.)

> Implement a concurrent test to benchmark throughput and latency of kerby KDC
> 
>
> Key: DIRKRB-574
> URL: https://issues.apache.org/jira/browse/DIRKRB-574
> Project: Directory Kerberos
>  Issue Type: Test
>Reporter: ChenQing
>Priority: Minor
>
> This would add a concurrent benchmark test to measure the throughput and 
> latency of Kerby KDC.



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


[jira] [Updated] (DIRKRB-574) Implement a concurrent test to benchmark throughput and latency of kerby KDC

2016-05-25 Thread Kai Zheng (JIRA)

 [ 
https://issues.apache.org/jira/browse/DIRKRB-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kai Zheng updated DIRKRB-574:
-
Summary: Implement a concurrent test to benchmark throughput and latency of 
kerby KDC  (was: Implement throughput and delay test,through a multithreaded )

> Implement a concurrent test to benchmark throughput and latency of kerby KDC
> 
>
> Key: DIRKRB-574
> URL: https://issues.apache.org/jira/browse/DIRKRB-574
> Project: Directory Kerberos
>  Issue Type: Test
>Reporter: ChenQing
>Priority: Minor
>
> Each perform the kinit main method can only start a thread to send socket 
> requests, and can't statistics the throughput and delay.



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


[jira] [Created] (DIRKRB-574) Implement throughput and delay test,through a multithreaded

2016-05-25 Thread ChenQing (JIRA)
ChenQing created DIRKRB-574:
---

 Summary: Implement throughput and delay test,through a 
multithreaded 
 Key: DIRKRB-574
 URL: https://issues.apache.org/jira/browse/DIRKRB-574
 Project: Directory Kerberos
  Issue Type: Test
Reporter: ChenQing
Priority: Minor


Each perform the kinit main method can only start a thread to send socket 
requests, and can't statistics the throughput and delay.



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


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

2016-05-25 Thread Jiajia Li (JIRA)

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

Jiajia Li commented on DIRKRB-542:
--

The update of the latest patch is great, with nice code format and with more 
RFC definitions.
The unit test for AD looks good to me and I can pass all the tests through the 
command "mvn clean package -Pnochecks",
I think the patch will be better if you can fix some pmd issues, you can run 
"mvn clean package" to find the pmd issues.

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


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

2016-05-25 Thread Jiajia Li (JIRA)

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

Jiajia Li commented on DIRKRB-542:
--

Thanks for the patch, but with some questions:
1. In PkinitAnonymousAsRepCodecTest.java, I think 
kdcDhKeyInfo.getDHKeyExpiration() is not null, why should be null?
2. AbstractIdentityBackend.java, the doGetIdentityAuthorizationData() function 
will always return null, where can we get the AuthorizationData?

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