You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Richard Sand <rs...@idfconnect.com> on 2018/12/23 18:31:11 UTC
Ehcache dependency version
Hi developers- is there any plan to update the ehcache dependency to v3 (currently v2.9 is used). When using the embedded ApcheDS for unit tests the v2 conflicts and there’s no mechanism I can see to turn the cache off
Thanks!
-Richard
Re: Ehcache dependency version
Posted by Emmanuel Lécharny <el...@gmail.com>.
Note: CCed the dev mailing, where it belongs to.
ApacheDS will simply store the password as provided, ie as a hash value
prepended with {SHA}, base64 encoded. It knows nothing about the
password, until someone tries to bind using this password. The check is
done by the SimpleAuthenticator.authenticate() method, which iterate
over the stored passwords, until it finds one match or none.
Matching the provided password with the stored password is done using
the PasswordUtil.compareCredentials( credentials, storedPassword )
method. This method can be checked outside of the server, it's a util
class and the method is static.
Can you check that the userPassword attribute values are containing one
value that match the provided passsword ?
The log you provided shows that no value matches, which means either the
provided clear text password is incorrect, or that the stored hashed
password value is not present.
On 27/12/2018 23:15, Richard Sand wrote:
> Hmm, not sure how that would be, since it works when the userpassword
> attribute in the LDIF is cleartext. When running the embedded DS with
> @ApplyLdifFiles({"test.ldif”}), doesn’t the DS recognize that the pwd
> attribute is already hashed if prepended with {SHA}?
>
>> On Dec 27, 2018, at 4:51 PM, Emmanuel Lecharny <elecharny@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Also it pop up in my mind that it may be a consequence of your cache
>> changes ?
>>
>> On Thu, Dec 27, 2018 at 7:17 AM Emmanuel Lécharny
>> <elecharny@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> On 26/12/2018 23:23, Richard Sand wrote:
>> > Thanks Emmanuel, I’m happy to help!
>> >
>> > By the way, at your suggestion, I changed my app to use
>> Caffeine for
>> > its in-memory cache - you’re right, it really is very trivial
>> to use!
>> > And it resolved the conflict with ehcache v2 vs v3 in the
>> embedded DS.
>> >
>> > One other odd roadblock I’ve hit today - is getting the embedded
>> > ApacheDS to authenticate simple binds when the test LDIF data has
>> > hashed passwords.
>> >
>> > My LDIF file has:
>> >
>> > dn: uid=monkey,ou=Users,ou=SSORest Eval,o=IDF Connect,c=US
>> > objectClass: inetOrgPerson
>> > ...
>> > uid: monkey
>> > userpassword:: 0oH9vgVVuRPRwp+ZFDo617xmz4M=
>>
>>
>> That won't work, because ApacheDS (or any other LDAP server) will
>> have
>> no clue about which hash function to use to hash the incoming
>> password
>> to compare it with the stored password.
>>
>>
>> The way it works :
>>
>> -inject a hashed password with the used hash method
>>
>> - then when a user tries to bind, providing a clear text
>> password, the
>> server will pull the hashed password from the database, get the hash
>> method from it, hash the provided password and compare it with the
>> provided hashed password
>>
>>
>> > I generated the above value by calling:
>> >
>> > String storagePwd = new String(
>> > PasswordUtil.createStoragePassword(
>> > password.getBytes(StandardCharsets.UTF_8),
>> > LdapSecurityConstants.HASH_METHOD_SHA
>> > ), StandardCharsets.UTF_8);
>> >
>> >
>> > But then when I do a simple bind in my unit test, I get the
>> error message:
>> >
>> > [2018-12-26
>> >
>> 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AbstractAuthenticator]
>>
>> > - [ERR_230 Password not correct for user
>> > ‘uid=monkey,ou=Users,ou=SSORest Eval,o=IDF Connect,c=US']
>> > [2018-12-26
>> >
>> 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AuthenticationInterceptor]
>>
>> > - [Authenticator
>> >
>> org.apache.directory.server.core.authn.SimpleAuthenticator@602fe822
>> > failed to authenticate: uid=monkey,ou=Users,ou=SSORest Eval,o=IDF
>> > Connect,c=US]
>> > [2018-12-26
>> >
>> 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AuthenticationInterceptor]
>>
>> > - [Cannot bind to the server ]
>> >
>> > I seem to be stuck on something trivial. I also followed the
>> sample
>> > code invoking MessageDigest as per
>> >
>> https://directory.apache.org/apacheds/basic-ug/3.1-authentication-options.html#but-how-to-obtain-the-hash-value-for-a-password
>>
>> > , but as expected it generated the same value as PasswordUtil…
>> >
>> > I’ve also tried specifying the attribute as:
>> >
>> > userpassword: {SHA}0oH9vgVVuRPRwp+ZFDo617xmz4M=
>>
>>
>> It should definitively work. We have a unit test that verifies it
>> works:
>>
>>
>> @Test
>> public void testSHA() throws Exception
>> {
>> apply( getService(), getUserAddLdif() );
>> String userDn = "uid=akarasulu,ou=users,ou=system";
>> LdapConnection connection = getConnectionAs( getService(),
>> userDn, "test" );
>>
>> // Check that we can get the attributes
>>
>> Entry entry = connection.lookup( userDn );
>> assertNotNull( entry );
>> assertTrue( entry.get( "uid" ).contains( "akarasulu" ) );
>>
>> // now modify the password for akarasulu : 'secret',
>> encrypted
>> using SHA
>> ModifyRequest modReq = new ModifyRequestImpl();
>> modReq.setName( new Dn( getService().getSchemaManager(),
>> userDn
>> ) );
>> modReq.replace( "userPassword",
>> "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=" );
>> connection.modify( modReq );
>>
>> // close and try with old password (should fail)
>> connection.close();
>>
>> try
>> {
>> connection.bind( userDn, "test" );
>> fail();
>> }
>> catch ( LdapAuthenticationException lae )
>> {
>> assertTrue( true );
>> }
>>
>> // try again now with new password (should be successful)
>> connection.bind( userDn, "secret" );
>> assertTrue( connection.isAuthenticated() );
>> ...
>>
>>
>> Are you 100% sure the password you try to bind with is the one
>> you hashed ?
>>
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com <http://www.iktek.com/>
>
Re: Ehcache dependency version
Posted by Richard Sand <rs...@idfconnect.com>.
Thanks Emmanuel, I’m happy to help!
By the way, at your suggestion, I changed my app to use Caffeine for its in-memory cache - you’re right, it really is very trivial to use! And it resolved the conflict with ehcache v2 vs v3 in the embedded DS.
One other odd roadblock I’ve hit today - is getting the embedded ApacheDS to authenticate simple binds when the test LDIF data has hashed passwords.
My LDIF file has:
dn: uid=monkey,ou=Users,ou=SSORest Eval,o=IDF Connect,c=US
objectClass: inetOrgPerson
...
uid: monkey
userpassword:: 0oH9vgVVuRPRwp+ZFDo617xmz4M=
I generated the above value by calling:
String storagePwd = new String(
PasswordUtil.createStoragePassword(
password.getBytes(StandardCharsets.UTF_8),
LdapSecurityConstants.HASH_METHOD_SHA
), StandardCharsets.UTF_8);
But then when I do a simple bind in my unit test, I get the error message:
[2018-12-26 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AbstractAuthenticator] - [ERR_230 Password not correct for user ‘uid=monkey,ou=Users,ou=SSORest Eval,o=IDF Connect,c=US']
[2018-12-26 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AuthenticationInterceptor] - [Authenticator org.apache.directory.server.core.authn.SimpleAuthenticator@602fe822 failed to authenticate: uid=monkey,ou=Users,ou=SSORest Eval,o=IDF Connect,c=US]
[2018-12-26 15:05:09.179][pool-5-thread-1][INFO][][o.a.d.s.c.a.AuthenticationInterceptor] - [Cannot bind to the server ]
I seem to be stuck on something trivial. I also followed the sample code invoking MessageDigest as per https://directory.apache.org/apacheds/basic-ug/3.1-authentication-options.html#but-how-to-obtain-the-hash-value-for-a-password , but as expected it generated the same value as PasswordUtil…
I’ve also tried specifying the attribute as:
userpassword: {SHA}0oH9vgVVuRPRwp+ZFDo617xmz4M=
Am I not formatting the LDIF properly for the embedded DS? Naturally it works fine when the userpassword attribute is in cleartext in the ldif.
Thanks!
Best regards,
Richard
> On Dec 26, 2018, at 5:42 AM, Emmanuel Lécharny wrote:
>
>
> On 26/12/2018 06:06, Richard Sand wrote:
>> Here it is…. It was more work than I thought!
>>
>> https://github.com/apache/directory-server/pull/9/files
>>
>> ehCache is upgraded from 2.10.4 to 3.6.1.
>>
>> Core class service, unit test codes, directory-cache.xml file…
>>
>> I look forward to your feedback. I wonder how much I broke…
>
>
> Whao ! A Xmas present !
>
>
> I'll have a look later as soon as I will be done with my big LDAP API refactoring - which is soon done -, hopefully later today or tomorrow.
>
>
> And, yes, I expected such a change to be a bit of hairy, considering the cache being used pretty everywhere in the server... That is probably the reason we didn't want to migrate to this new version with a slightly different API.
>
>
> Many thanks, Richard !
>
>
Re: Ehcache dependency version
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 26/12/2018 06:06, Richard Sand wrote:
> Here it is…. It was more work than I thought!
>
> https://github.com/apache/directory-server/pull/9/files
>
> ehCache is upgraded from 2.10.4 to 3.6.1.
>
> Core class service, unit test codes, directory-cache.xml file…
>
> I look forward to your feedback. I wonder how much I broke…
Whao ! A Xmas present !
I'll have a look later as soon as I will be done with my big LDAP API
refactoring - which is soon done -, hopefully later today or tomorrow.
And, yes, I expected such a change to be a bit of hairy, considering the
cache being used pretty everywhere in the server... That is probably the
reason we didn't want to migrate to this new version with a slightly
different API.
Many thanks, Richard !
Re: Ehcache dependency version
Posted by Richard Sand <rs...@idfconnect.com>.
Here it is…. It was more work than I thought!
https://github.com/apache/directory-server/pull/9/files
ehCache is upgraded from 2.10.4 to 3.6.1.
Core class service, unit test codes, directory-cache.xml file…
I look forward to your feedback. I wonder how much I broke…
Best regards,
Richard
> On Dec 24, 2018, at 1:10 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>
> On 24/12/2018 05:26, Richard Sand wrote:
>> Hi Emmanuel - yeah there are a few notable differences in ehcache 3.x - I’m about halfway through getting everything to compile. The notable differences I’ve found are:
>>
>> 1 - the Cache object now uses generics i.e. Cache<K,V> - the put methods no longer use an Entry object but take K,V directly
>> 2 - the configuration methods do more of the work but expose fewer of the properties programmatically - notably there are places where the current code updates the cache configurations after initialization, which I believe probably isn’t needed anyway but nonetheless doesn’t seem to be supported in v3
>>
>> Caffeine says it has a JSR-107 wrapper - will you implement Caffeine directly or via JSR-107?
>
> I have'nt made my mind yet. What is certain is that we would like to be able to switch the implementation easily, and if it requires using the JSR-107 API, so be it.
>
>
>>
>> I’ll submit a pull request soon anyway so you can see the changes I made to support ehcache v3 and decide if you want to keep them or not.
>
>
> Sure !
>
>
> Thanks !
>
Re: Ehcache dependency version
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 24/12/2018 05:26, Richard Sand wrote:
> Hi Emmanuel - yeah there are a few notable differences in ehcache 3.x - I’m about halfway through getting everything to compile. The notable differences I’ve found are:
>
> 1 - the Cache object now uses generics i.e. Cache<K,V> - the put methods no longer use an Entry object but take K,V directly
> 2 - the configuration methods do more of the work but expose fewer of the properties programmatically - notably there are places where the current code updates the cache configurations after initialization, which I believe probably isn’t needed anyway but nonetheless doesn’t seem to be supported in v3
>
> Caffeine says it has a JSR-107 wrapper - will you implement Caffeine directly or via JSR-107?
I have'nt made my mind yet. What is certain is that we would like to be
able to switch the implementation easily, and if it requires using the
JSR-107 API, so be it.
>
> I’ll submit a pull request soon anyway so you can see the changes I made to support ehcache v3 and decide if you want to keep them or not.
Sure !
Thanks !
Re: Ehcache dependency version
Posted by Richard Sand <rs...@idfconnect.com>.
Hi Emmanuel - yeah there are a few notable differences in ehcache 3.x - I’m about halfway through getting everything to compile. The notable differences I’ve found are:
1 - the Cache object now uses generics i.e. Cache<K,V> - the put methods no longer use an Entry object but take K,V directly
2 - the configuration methods do more of the work but expose fewer of the properties programmatically - notably there are places where the current code updates the cache configurations after initialization, which I believe probably isn’t needed anyway but nonetheless doesn’t seem to be supported in v3
Caffeine says it has a JSR-107 wrapper - will you implement Caffeine directly or via JSR-107?
I’ll submit a pull request soon anyway so you can see the changes I made to support ehcache v3 and decide if you want to keep them or not.
Thanks!
Best regards,
Richard
> On Dec 23, 2018, at 11:13 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>
> On 23/12/2018 21:16, Stefan Seelmann wrote:
>> Hi Richard,
>>
>> I don't think it is planned.
>
> What I expect to do is to get rid of ehcache completely in favor of Caffeine (https://github.com/ben-manes/caffeine).
>
> I did some tests a few months ago, and I can say it's lightweight compared to ehcache, and more efficient.
>
> Regarding a move to ehcache 3.0, IFAIR, the API change a bit. ATM, the trunk is using ehcache 2.10.4.
Re: Ehcache dependency version
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 23/12/2018 21:16, Stefan Seelmann wrote:
> Hi Richard,
>
> I don't think it is planned.
What I expect to do is to get rid of ehcache completely in favor of
Caffeine (https://github.com/ben-manes/caffeine).
I did some tests a few months ago, and I can say it's lightweight
compared to ehcache, and more efficient.
Regarding a move to ehcache 3.0, IFAIR, the API change a bit. ATM, the
trunk is using ehcache 2.10.4.
Re: Ehcache dependency version
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/23/18 9:25 PM, Richard Sand wrote:
> I don’t think any code changes are required it’s just updating the pom. I’ll give it a shot tonight, thanks Stefan! But do you think there should be a config option to disable the cache entirely for just this type of case?
Yes, sounds reasonable to be able to disable the cache. Maybe even allow
pluggable cache implementation by switching to JCache/JSR-107?
Please note that there seem to be 4 test failures currently in master
[1], so don't get confused when building...
Kind Regards,
Stefan
[1]
https://builds.apache.org/view/D/view/Directory/job/dir-apacheds-ubuntu-deploy/
Re: Ehcache dependency version
Posted by Richard Sand <rs...@idfconnect.com>.
I don’t think any code changes are required it’s just updating the pom. I’ll give it a shot tonight, thanks Stefan! But do you think there should be a config option to disable the cache entirely for just this type of case?
Sent from my iPhone
> On Dec 23, 2018, at 3:16 PM, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
>
> Hi Richard,
>
> I don't think it is planned. Did you try updating? Are there any/many
> code changes required? Can you provide a patch or pull request?
>
> Kind Regards,
> Stefan
>
>> On 12/23/18 7:31 PM, Richard Sand wrote:
>> Hi developers- is there any plan to update the ehcache dependency to v3 (currently v2.9 is used). When using the embedded ApcheDS for unit tests the v2 conflicts and there’s no mechanism I can see to turn the cache off
>>
>> Thanks!
>>
>> -Richard
>>
>
Re: Ehcache dependency version
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Richard,
I don't think it is planned. Did you try updating? Are there any/many
code changes required? Can you provide a patch or pull request?
Kind Regards,
Stefan
On 12/23/18 7:31 PM, Richard Sand wrote:
> Hi developers- is there any plan to update the ehcache dependency to v3 (currently v2.9 is used). When using the embedded ApcheDS for unit tests the v2 conflicts and there’s no mechanism I can see to turn the cache off
>
> Thanks!
>
> -Richard
>