manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Schuch" <markus_sch...@web.de>
Subject Re: How to map the atlassian confluence security model to manifoldcf
Date Sun, 26 May 2013 00:20:34 GMT
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" <daddywri@gmail.com>
An: "user@manifoldcf.apache.org" <user@manifoldcf.apache.org>
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 <markus_schuch@web.de> 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

Mime
View raw message