cancel
Showing results for 
Search instead for 
Did you mean: 

How to override the default security ACL to make it case-insensitive to the username ?

fast_narcis_
Confirmed Champ
Confirmed Champ

We have a messy AD where not all email addresses are in lower case. Some are capitalized and some are not. Because of this, a user may login with USer@acme.com or user@acme.com . I see in the ACLS table that the permissions are stored both ways, depending on how the user was logged in at the time the documents were created.

So, because of this, sometimes a user doesn't have access to basic functionality like edit it's own profile or access the personal workspace.

1 ACCEPTED ANSWER

Olivier_Grisel
Star Contributor
Star Contributor

Since Nuxeo 5.4.2, you can force the id case of the directory entries to "lower" or "upper" in the LDAPDirectory configuration with: <idCase>lower</idCase> for instance. The default value for that parameter is "unchanged".

That should fix your issue without having to mess with the ACL system. Nuxeo principal ids are must be unique, not only for the ACL system but also for looking up documents by creator id for instance.

View answer in original post

10 REPLIES 10

Olivier_Grisel
Star Contributor
Star Contributor

Since Nuxeo 5.4.2, you can force the id case of the directory entries to "lower" or "upper" in the LDAPDirectory configuration with: <idCase>lower</idCase> for instance. The default value for that parameter is "unchanged".

That should fix your issue without having to mess with the ACL system. Nuxeo principal ids are must be unique, not only for the ACL system but also for looking up documents by creator id for instance.

It would be great if it would work like that, but it doesn't.

I don't see the issue, if you do the change on the LDAPDirectory configuration, the SQLDirectory will naturally fill in it's entries with lowercase ids only.

I've cleared the data folder so I have clean data.

Alright I think we can say that this qualifies as a bug. Can you please open a jira issue? I think we should make the SQLDirectory and / or MultiDirectory able to handle the idCase param as well to make them behave consistently.

I already tried that but I have contributed a extension to the UserManager overriding the makePrincipal method, but the id is null at that point.

Indeed overriding makePrincipal is useless since the user entry is already fetched from the user directory when this method is called. Override getPrincipal as I said previously instead

Also I have entered support ticket SUPNXP-4618 for the same.

It worked like this

Getting started

Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.