...

For example, assuming I have one document named “management_procedure.pdf” and that this document has “1” as ID and that the groups “managers” and “developers” have read access to it. I need to have the following table or view named “acl_view” in my database:

Now if I perform the following query:

...

This is were the real difference between the two cases presented in introduction happens !

1. Database documents ACLs managed by an Active Directory/LDAP

If the documents ACLs are managed by an Active Directory/LDAP then you need to /wiki/spaces/DATAFARI/pages/223313957. Be careful though, the authority connector needs to be linked to the same authority group as the JDBC repository connector used in the job ! If the AD/LDAP authority connector has been automatically created by the AD/LDAP configuration UI of Datafari, it will for sure not be in the same authority group, you will need to change it manually in the “Type” tab of the authority connector ! To better understand the reasons of this and the best practices concerning authority connectors please read this documentation: /wiki/spaces/DATAFARI/pages/2188115979

Next, ensure that the ACLs returned by the authority connector are of the same kind and can match the access tokens returned by the data table/view you used in the job configuration of the JDBC connector. If this is not the case, then you will need to modify your table/view so that they are compatible and that a user allowed to access to a specific database document has matching authority connector token(s) with the access tokens of the document

2. Database documents ACLs managed by the Database itself

If the documents ACLs are managed internally by the database, then you will need to configure a JDBC authority connector that will connect to the database and retrieve the access tokens of users. To do that, follow these steps:

...

The “user ID query” is only mandatory if the table/view used in the authorization tokens query only works with database user IDs and that you need to perform a mapping between usernames (samaccount@domain) and database user IDs. If defined, it must use the $(IDCOLUMN) parameter that is used by the connector to identify the user database ID, and the $(USERNAME) parameter that is replaced by the connector by the username provided by Datafari during search

The “authorization tokens query” must use the $(TOKENCOLUMN) that is used by the connector to identify in a result set the auth token of the user, and either the $(UID) or the $(USERNAME) or both depending if the table/view used in the query is working with usernames (samaccount@domain) or database user IDs (the $(UID) parameter is replaced by the user ID returned by the “user ID query”). Also, the “authorization tokens query” must return one result tuple per user authorization token. Here is an example of a compatible user_authorizations table/view for the “authorization tokens query”:

With that kind of table/view, the “authorization tokens query” would be

...