manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: How to map the atlassian confluence security model to manifoldcf
Date Sat, 25 May 2013 14:54:07 GMT
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.


On Fri, May 24, 2013 at 6:57 PM, Markus Schuch <> 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:
> 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

View raw message