nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Dynamic authority and facet

sammasue

Dear all,

I have a custom dynamic authority and in order to make the search working I disabled the permissions check on Solr ("alfresco.doPermissionChecks=false"). So then, the results are filtered on the Repository such that my dynamic authority is applied. It works well, however I get incorrect facets. It actually makes sense because they have been computed on Solr before the resultSet is filtered.

I am blocked on this facet issue, so I'm looking for help, any ideas ?

Thanks

Find more posts tagged with

Comments

afaust

What does your dynamic authority represent / work with? If possible, I'd try not to use a dynamic authority for basic read permissions and only for state-based create/update/delete if I absolutely have to.

I currently am working on a project where I could have used dynamic authorities for most of the permission management, but have opted for the harder option of using event-based policies and systems-managed (transparent) groups because this is far better supported - not just in SOLR, but also some of the dynamic workflow assignement use cases I will have to deal with soon. It also is easier to grasp and deal with for other devs on my team.

Regards
Axel

sammasue

Thank you for answer.

I created a dynamic authority to call via a webservice another application which computes if yes/no the user has access to a node.
It's for read permissions only and only for documents. Why doing this? because in my case, group-based access rights are too static. Indeed, our access rights are based on rules which are applied at the level of my organisation. E.g. supervisors have access to supervisees' docs, there are internal roles, signatories, and many many others, … So I developped this external application which uses a rules engine to do the work. Using caching I'm able to have a correct response time. For us, it is much easier to add new rules, to always be up to date and to get the reason why someone has access. Then I could use this application not only with Alfresco. It's currently working except for the facets.

At the end, Alfresco does almost nothing on documents. I understand how problematic it can be to use these dynamic authorities in certain cases and why you try to fit your requirements with event-based policies and systems-managed groups. I haven't thought about problems which could happen with the workflow, it's interesting, I need to think about it more.

Regards
Samuel

afaust

Thanks for explaining. I certainly understand the use case for rule-based permissions. The main problem in this case is that it covers the read permission which is handled specially in some corners of Alfresco.

In the project I'm working on we have - to some degree - built basic rules within Alfresco and associated each rule with a technical group authority (transparent to users). Whenever a rule is changed, it's previous and new configuration are used to select affected nodes and grant/revoke permissions (including read) to the group. Actual users and groups are then set to be "role-managed" a certain rule and are transparently made members of the technical group, inheriting its node-level permissions.
This approach works from a performance point of view because we have a somewhat static base structure and rules apply to roots / sub-branches of the structure, not individual documents as in your case.

One solution I can think of that doesn't involve hacking SOLR directly: If you could generate Alfresco FTS queries from the configured rule set (including dynamic fragments based on the current user, the organisation level and such), then you could use those as filter queries in SOLR which would a) reduce post-query permission checking on the Repository tier and b) also restrict the facet values. Essentially, this is what the default SOLR permission checking is doing - adding a second query to filter the raw results.

In Alfresco 5.0, the Java SearchParameters class allows passing in "extraParameters" directly to SOLR, which can be a single "fq" (filter query) parameter. Unfortunately, there is no intentional extension point to hook into to ensure that "fq" is always set, but technically speaking it would be possible to add an AOP interceptor to the SearchService and transparently enhance every search request.

Apart from this comparatively minor hack on the Repository tier, the only other option (except living with incorrect facet counts) would involve adding some form of custom query handler on the SOLR tier to trim raw results before facets are collected.

Regards
Axel

sammasue

Thank you very much Axel your answer, this is precious information.

You mentioned the read permission is handled specially, do you mind if I ask you to tell me more about it? What I know so far about it are these issues I had using a dynamic authority:
- Search: Solr checks the read permission on nodes. So if the logic is not the same in Alfresco and Solr then it's gonna bring inconsistency.
- Facet: disabling check permission on Solr can solve the previous issue. Indeed, Solr will return more results but Alfresco will filter them. The problem is that all the stats and facets processed by Solr will be wrong.
- Thumbnails: the permissions on thumbnails are inherited from the documents such that permissions are sync. But dynamic authorities could return false for a thumbnail whereas it returns true on the document.
- Workflow assignment as you said.

I don' t know yet which solution I'm going to choose for my problem, but for sure I have a better understanding of the situation. I don't know if other people are following this post, I would be really interested in knowing if someone customized/extended Solr? especially to filter out results ?

Best regards,
Sam

afaust

The "Read" permission in Alfresco is actually made up of "ReadProperties", "ReadContent" and "ReadChildren". Only "ReadProperties" would be technically required to view a node in a simple listing without accessing any content or sub-nodes. The Alfresco SearchService will always check for the aggregate "Read" permission when filtering results on the Repository tier, because for all intents and purposes, a real UI would require all constituent permission to be granted. Similarily, the SOLR filtering is also based entirely on the aggregate "Read" permission.

The main difference in filtering between SOLR and Repository originates from the difference in static checks and static+dynamic checks.

When SOLR indexes ACLs for nodes, it only indexes the statically defined permissions - essentially, the Repository pre-calculates a set of read-allowed authorities. Technically speaking, the Repository performs a regular permission check but limits the authorities it checks (for performance reasons) to those that have any statically defined permission assigned within the ACL and does not include any dynamic authorities as it calculates the set for an ACL, not a specific node.

When the Repository tier filters the unfiltered results from SOLR, it does a full permission check on specific nodes including all the dynamic authorities that may apply. Of course all facets / statistics returned from SOLR don't have any association to nodes anymore so can't be filtered accordingly.

In a different project we have indeed customized / extended SOLR, i.e. removing some technical limitations of Alfresco SOLR 1.x as well as 4.x (URL length limit issues with facets / complex searches, adding/enhancing support for query facets / filters, minor improvements to cache control), but we have not yet customized anything in regards to permission checking. Most of our customizations are simple request handler facades and don't dive into the actual query internals, which can be quite complex to handle.

sammasue

I understand, thanks for this additional information. I don't know yet in which direction I will go. I'll let you know if I succeed to do something interesting enough to be shared.