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 > > 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 >
