Hi Karl, no need to apologize... a response in less than 24 hours to an open source project's mailing list entry is perfect to me ;) - so thank you for the quick response and thank you for sacrificing your valuable holiday weekend time.
The confluence API returns user and/or group names when requesting permissions for a page. see: https://developer.atlassian.com/display/CONFDEV/Remote+Confluence+Methods#RemoteConfluenceMethods-Permissions.1 https://developer.atlassian.com/display/CONFDEV/Remote+Confluence+Data+Objects#RemoteConfluenceDataObjects-contentpermissionContentPermission But the API methods for retrieving page permissions do not respect permissions inherited from parent pages which is very sad. (refer to https://jira.atlassian.com/browse/CONF-14965) To workaround this problem we will have to write a confluence plugin that can give us the effective permissions for a page. We looked into that and we think it is possible. In theory the effective page permissions retrieved by our plugin would be a list of group names and/or usernames. The groupnames have to be ANDed to respect permissions inherited from parent pages. We can concatenate all needed combinations of group and user names to single accesstokens to create a "flattened" version of the permission hierarchy. So good so far... But another problem arises: The authority connector would also have to return accesstokens that are compatible to the flattened permission hierachy and therefore we must build all possible permutations of the user's groupnames. If our math is correct, there will be (2^n)-1 access tokens for a user (where n is the number of distinct groups the user is member of). Additionally there will be more combinations with the username. This will most probably not perform well for users with many group memberships. I see these 2 options: - We could implement folder level accesstokens for a constant number X of folder levels. So the outputconnector would need to reject documents with a number of folder levels greater X. May be there is built in limit of page levels in confluence... if not, that this solution is not ideal. - Start to think about post filtering... Regards, Markus ----------------------------------------- Gesendet: Samstag, 25. Mai 2013 um 16:54 Uhr Von: "Karl Wright" <[email protected]> An: "[email protected]" <[email protected]> Betreff: Re: How to map the atlassian confluence security model to manifoldcf Hi Marcus, Sorry for the slow response - it is a holiday weekend in the States, and that has managed to impact me to some degree. Anyhow, I've looked at the doc on Atlassian security, and I have some questions. First, when you call the Atlassian API, and request security information for a document, in what form does it come back? If it comes back as a minimal list of groups and users which can see the document, then you probably just want the access tokens for this connector to be group names/ids and user names/ids. If it is more complicated, and basically you have to ascend the hierarchy either explicitly or implicitly, then we'll have to work a bit harder. Either we'll have to find a flat mapping of folders to access tokens, or we'll have to look at extending the framework to handle more stuff. As far as the folder-level security, the reason it is deprecated at the moment is because it is very challenging to implement properly in a standard search engine with a fixed schema, since there are N possible folder parents, where N is determined by an individual document. Furthermore, the model is not really applicable to the case where there is a hierarchy that cannot be flattened. But, depending on what the answer is to my question above, if needed we can try to come up with a workable folder implementation, and extend the Solr connector and plugins as well. Karl On Fri, May 24, 2013 at 6:57 PM, Markus Schuch <[email protected]> wrote:Hi, we are currently writing a repository connector for confluence. We are using the solr output connection on Solr 4.x. Seeding, versioning, processing works already and now we have to face security. Compared to the already supported repositories by mcf, confluence seems to have a different security model. There are "Space" permissions for a whole wiki space and these can easily be mapped as shareAllowTokens but there are also page restrictions. Page restrictions are attached to each page (page = document) and page restrictions are inherited. See "Example of Child Page Restrictions" in the Confluence Doc: https://confluence.atlassian.com/display/DOC/Page+Restrictions[https://confluence.atlassian.com/display/DOC/Page+Restrictions] The inheritance of page restrictions makes things difficult. If we are correct, than it is not sufficient to add the page restrictions as document level access tokens, because the query time filtering handels the user's access tokens (e.g. group memberships) as disjunction. Instead we probalby need a hierarchic, folder based structure of access tokens to map the inheritance of the page restrictions correctly. The current Solr SearchComponent does not support folder level access tokens and the book (mcf in action) says, that these kind of tokens are considered deprecated. To cut a long story short... we are stuck at the moment. Our questions: Did anyone already manage to map confluence security to mcf/solr? Or does somebody has an idea how a confluence-like security model can be mapped to mcf/solr? Thanks in advance Markus
