Return-Path: X-Original-To: apmail-manifoldcf-user-archive@www.apache.org Delivered-To: apmail-manifoldcf-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4A341D0BE for ; Thu, 30 May 2013 11:29:12 +0000 (UTC) Received: (qmail 9341 invoked by uid 500); 30 May 2013 11:29:11 -0000 Delivered-To: apmail-manifoldcf-user-archive@manifoldcf.apache.org Received: (qmail 9191 invoked by uid 500); 30 May 2013 11:29:11 -0000 Mailing-List: contact user-help@manifoldcf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@manifoldcf.apache.org Delivered-To: mailing list user@manifoldcf.apache.org Received: (qmail 9164 invoked by uid 99); 30 May 2013 11:29:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 May 2013 11:29:10 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of daddywri@gmail.com designates 209.85.220.173 as permitted sender) Received: from [209.85.220.173] (HELO mail-vc0-f173.google.com) (209.85.220.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 May 2013 11:29:03 +0000 Received: by mail-vc0-f173.google.com with SMTP id ht10so66747vcb.32 for ; Thu, 30 May 2013 04:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1nreqlLxGQGGykuUZZnfm/FP5pfGQEP5m1TqaMTOuFE=; b=uadnYh4tVzw/19wK8u3JjNbCv+TKYVJ3Nf8oUyNPardk1i+XNeuACq4zsQ/sBMA09q 8zJebhYMvhIiFH5Kx5YoNH4Hvvx+eiH4BUydL3b6km9LL1I5BFdlgv1SjIgkYiRJN6IC qFGk8ipW3gC0OOCTE7a1sYpStWiqeoywBE+HD5nuZhSQ1OK6SCsfsEe+yTUP3RxUrHYD oESJMw0OKS13WID7kDxHcWrjCdWLwyAHTI+IasoNH5c50TP8afF8y8XrtPooGMRsL7Hb n4mOKshYlPKiMOMhirToV4nNdg4EWcOGwpHHSzZaPzUG94FbmWHRnTPiVYsxAdphuhEm wElQ== MIME-Version: 1.0 X-Received: by 10.52.165.36 with SMTP id yv4mr4308930vdb.31.1369913322880; Thu, 30 May 2013 04:28:42 -0700 (PDT) Received: by 10.58.94.81 with HTTP; Thu, 30 May 2013 04:28:42 -0700 (PDT) In-Reply-To: <51A735C5.2090301@web.de> References: <51A735C5.2090301@web.de> Date: Thu, 30 May 2013 07:28:42 -0400 Message-ID: Subject: Re: How to map the atlassian confluence security model to manifoldcf From: Karl Wright To: "user@manifoldcf.apache.org" Content-Type: multipart/alternative; boundary=001a11c2c010fbeccb04ddedcc2f X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2c010fbeccb04ddedcc2f Content-Type: text/plain; charset=ISO-8859-1 "But my colleague is worried that this solution does not scale well on solr and that we will have to deal with very long user lists. (We implement this for a ~300,000 people company)." I think Solr will be fine here. This is no worse than a document that has 300000 words, and Solr performs queries against such documents very well. The only real concern is how long ManifoldCF will take to post such documents to Solr, and whether you need to give it more memory. ;-) At some point this obviously would break down, but I don't think we'll see a company that big in my lifetime. Karl On Thu, May 30, 2013 at 7:19 AM, Markus Schuch wrote: > Hi Karl, > > sorry for not beeing very responsive. > We had a lot to do this week. We created a confluence plugin to add an api > to > confluence that can give us all the information about permissions we need. > > Your proposal to calculate the minimal user/group list (take groups where > possible, create intersection of userlists where needed) sounds promising > to me. > But my colleague is worried that this solution does not scale well on solr > and > that we will have to deal with very long user lists. (We implement this > for a > ~300,000 people company). At the moment we don't know how long the biggest > userlist will be. > > So, the next step is to examine the content and the permissions after our > admins > installed the brand new plugin. When we have an overview how our admins > work > with page permissions and how big our groups and the resulting intersected > user > lists are, than we will decide which way to go. > > I'll keep you updated. > > Markus > > Am 30.05.2013 12:17, schrieb Karl Wright: > > Hi Markus, > > > > Have you had any luck with this? > > > > Karl > > > > > > > > On Sun, May 26, 2013 at 9:32 AM, Karl Wright > > wrote: > > > > Hi Markus, > > > > The usual way these things map is that there is an API call that > gets a list > > of groups and users that can see > > the resource, and *maybe* there's a list of groups and users that are > > prohibited from seeing the resource. > > These user ids and group ids get used as access tokens. The > semantics of > > the ManifoldCF access tokens are that prohibitions supercede > allowances. > > The authority service then simply returns the user id and a list of > > group ids to which the user belongs, provided such functionality > exists in > > the API. > > > > In the case of Atlassian, where parents have both prohibition lists > as well > > as allowance lists, it is usually the case that the prohibition > lists can > > simply be unioned when they are flattened. Being a member of any > prohibited > > group in the hierarchy is sufficient to exclude a user from seeing > the > > resource. For allowance > > lists, however, it is not possible to merge the lists in a simple > way, since > > as you point out you are trying to > > capture an "AND" relationship. To make this concrete, say you have > three > > objects - A->B->C, and let's say > > P(A) is the allow list for A, P(B) for B, etc. Then, you want > > "user_in(P(A)) AND user_in(P(B)) AND user_in(P(C))". > > > > I agree that the only viable way to flatten this is to create an > access > > token for every combination of group > > permissions you are likely to see. So if there were the groups G1 > G2 G3 G4 > > and G5, there would have to be > > access tokens for "G1 AND G2", "G2 AND G3", "G1 AND G2 AND G3", etc. > The > > authority service would then be stuck returning a combinatorially > large > > number of access tokens, and that would not do at all. > > > > An alternative is to try and find a way to implement the AND > relationship > > between access tokens natively. > > To do it his way requires an open-ended and potentially > combinatorially > > large number of index fields. You'd > > need one such field per page, seems to me. In theory Solr has a way > of > > creating N fields at index time, where > > you just use a special field prefix, and the field is created. But > there > > are two problems with this. First, > > at query time, the Lucene query the Solr plugin would need to build > would > > contain a clause for every page in > > Atlassian. That's not going to work. Second, we'd need a default > value for > > access tokens for all pages in > > Atlassian for every document indexed, and I don't think that's > configurable > > in Solr either. > > > > Another alternative is to post-filter results. This will require > > significant support in ManifoldCF, especially in the > > authority connector, but it could be added with not too much > trouble. The > > downside is that there are going to > > be cases where one would need to go through a lot of results to find > the few > > that one is allowed to see. I'm > > willing to do this, though, if there are no better alternatives. > > > > But there's one more possibility, which is worth thinking about. > > Specifically, try the approach of actually calculating the minimal > > user/group list for the document, at indexing time. So the access > tokens > > are group id's and user id's, and the connector logic actually > calculates > > the minimal intersection of P(A), P(B), and P(C) in the example > above. > > > > Example 1: > > P(A) was G1 or G2 > > P(B) was G2 or G3 > > P(C) was G4 > > > > ...then the logic would explicitly find all users which matched ALL > of those > > criteria - which would mean that the > > access token list for the document would be a list of individual > user id's > > in this case, not groups - specifically the list of user ids of > those users > > that belong to G2 AND G4. > > > > Example 2: > > P(A) was G1 or G2 or G3 > > P(B) was G2 or G3 > > P(C) was G3 > > > > ...then the logic would return just the group id for G3. > > > > The only problem with this approach that I can see is that if the > sysadmin > > structures things like example 1, the > > only way a user would be rendered unable to see such a document > would be via > > reindexing. Changing the user's group affinity alone would not be > > sufficient in that case. However, I strongly suspect that real > Atlassian > > sysadmins do things more like Example 2 than Example 1. What do you > think? > > > > Karl > > > > > > > > On Sat, May 25, 2013 at 8:20 PM, Markus Schuch > > wrote: > > > > 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] > > < > https://confluence.atlassian.com/display/DOC/Page+Restrictions%5Bhttps://confluence.atlassian.com/display/DOC/Page+Restrictions%5D > > > > > > 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 > > > > > > > --001a11c2c010fbeccb04ddedcc2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"But my colleague is worried that this solu= tion does not scale well on solr and
that we will have to deal with very long user lists. (We implement this for= a
~300,000 people company)."

I think Solr will be fine here= .=A0 This is no worse than a document that has 300000 words, and Solr perfo= rms queries against such documents very well.=A0 The only real concern is h= ow long ManifoldCF will take to post such documents to Solr, and whether yo= u need to give it more memory. ;-)

At some point this obviously would break down, but I don'= ;t think we'll see a company that big in my lifetime.
Karl
=


On Thu,= May 30, 2013 at 7:19 AM, Markus Schuch <markus_schuch@web.de> wrote:
Hi Karl,

sorry for not beeing very responsive.
We had a lot to do this week. We created a confluence plugin to add an api = to
confluence that can give us all the information about permissions we need.<= br>
Your proposal to calculate the minimal user/group list (take groups where possible, create intersection of userlists where needed) sounds promising t= o me.
But my colleague is worried that this solution does not scale well on solr = and
that we will have to deal with very long user lists. (We implement this for= a
~300,000 people company). At the moment we don't know how long the bigg= est
userlist will be.

So, the next step is to examine the content and the permissions after our a= dmins
installed the brand new plugin. When we have an overview how our admins wor= k
with page permissions and how big our groups and the resulting intersected = user
lists are, than we will decide which way to go.

I'll keep you updated.

Markus

Am 30.05.2013 12:17, schrieb Karl Wright:
> Hi Markus,
>
> Have you had any luck with this?
>
> Karl
>
>
>
> On Sun, May 26, 2013 at 9:32 AM, Karl Wright <daddywri@gmail.com
> <mailto:daddywri@gmail.com>> wrote:
>
> =A0 =A0 Hi Markus,
>
> =A0 =A0 The usual way these things map is that there is an API call th= at gets a list
> =A0 =A0 of groups and users that can see
> =A0 =A0 the resource, and *maybe* there's a list of groups and use= rs that are
> =A0 =A0 prohibited from seeing the resource.
> =A0 =A0 These user ids and group ids get used as access tokens. =A0The= semantics of
> =A0 =A0 the ManifoldCF access tokens are that prohibitions supercede a= llowances.
> =A0 =A0 The authority service then simply returns the user id and a li= st of
> =A0 =A0 group ids to which the user belongs, provided such functionali= ty exists in
> =A0 =A0 the API.
>
> =A0 =A0 In the case of Atlassian, where parents have both prohibition = lists as well
> =A0 =A0 as allowance lists, it is usually the case that the prohibitio= n lists can
> =A0 =A0 simply be unioned when they are flattened. =A0Being a member o= f any prohibited
> =A0 =A0 group in the hierarchy is sufficient to exclude a user from se= eing the
> =A0 =A0 resource. =A0For allowance
> =A0 =A0 lists, however, it is not possible to merge the lists in a sim= ple way, since
> =A0 =A0 as you point out you are trying to
> =A0 =A0 capture an "AND" relationship. =A0To make this concr= ete, say you have three
> =A0 =A0 objects - A->B->C, and let's say
> =A0 =A0 P(A) is the allow list for A, P(B) for B, etc. =A0Then, you wa= nt
> =A0 =A0 "user_in(P(A)) AND user_in(P(B)) AND user_in(P(C))".=
>
> =A0 =A0 I agree that the only viable way to flatten this is to create = an access
> =A0 =A0 token for every combination of group
> =A0 =A0 permissions you are likely to see. =A0So if there were the gro= ups G1 G2 G3 G4
> =A0 =A0 and G5, there would have to be
> =A0 =A0 access tokens for "G1 AND G2", "G2 AND G3"= , "G1 AND G2 AND G3", etc. =A0The
> =A0 =A0 authority service would then be stuck returning a combinatoria= lly large
> =A0 =A0 number of access tokens, and that would not do at all.
>
> =A0 =A0 An alternative is to try and find a way to implement the AND r= elationship
> =A0 =A0 between access tokens natively.
> =A0 =A0 To do it his way requires an open-ended and potentially combin= atorially
> =A0 =A0 large number of index fields. =A0You'd
> =A0 =A0 need one such field per page, seems to me. =A0In theory Solr h= as a way of
> =A0 =A0 creating N fields at index time, where
> =A0 =A0 you just use a special field prefix, and the field is created.= =A0But there
> =A0 =A0 are two problems with this. =A0First,
> =A0 =A0 at query time, the Lucene query the Solr plugin would need to = build would
> =A0 =A0 contain a clause for every page in
> =A0 =A0 Atlassian. =A0That's not going to work. =A0Second, we'= d need a default value for
> =A0 =A0 access tokens for all pages in
> =A0 =A0 Atlassian for every document indexed, and I don't think th= at's configurable
> =A0 =A0 in Solr either.
>
> =A0 =A0 Another alternative is to post-filter results. =A0This will re= quire
> =A0 =A0 significant support in ManifoldCF, especially in the
> =A0 =A0 authority connector, but it could be added with not too much t= rouble. =A0The
> =A0 =A0 downside is that there are going to
> =A0 =A0 be cases where one would need to go through a lot of results t= o find the few
> =A0 =A0 that one is allowed to see. =A0I'm
> =A0 =A0 willing to do this, though, if there are no better alternative= s.
>
> =A0 =A0 But there's one more possibility, which is worth thinking = about.
> =A0 =A0 Specifically, try the approach of actually calculating the min= imal
> =A0 =A0 user/group list for the document, at indexing time. =A0So the = access tokens
> =A0 =A0 are group id's and user id's, and the connector logic = actually calculates
> =A0 =A0 the minimal intersection of P(A), P(B), and P(C) in the exampl= e above.
>
> =A0 =A0 Example 1:
> =A0 =A0 P(A) was G1 or G2
> =A0 =A0 P(B) was G2 or G3
> =A0 =A0 P(C) was G4
>
> =A0 =A0 ...then the logic would explicitly find all users which matche= d ALL of those
> =A0 =A0 criteria - which would mean that the
> =A0 =A0 access token list for the document would be a list of individu= al user id's
> =A0 =A0 in this case, not groups - specifically the list of user ids o= f those users
> =A0 =A0 that belong to G2 AND G4.
>
> =A0 =A0 Example 2:
> =A0 =A0 P(A) was G1 or G2 or G3
> =A0 =A0 P(B) was G2 or G3
> =A0 =A0 P(C) was G3
>
> =A0 =A0 ...then the logic would return just the group id for G3.
>
> =A0 =A0 The only problem with this approach that I can see is that if = the sysadmin
> =A0 =A0 structures things like example 1, the
> =A0 =A0 only way a user would be rendered unable to see such a documen= t would be via
> =A0 =A0 reindexing. =A0Changing the user's group affinity alone wo= uld not be
> =A0 =A0 sufficient in that case. =A0However, I strongly suspect that r= eal Atlassian
> =A0 =A0 sysadmins do things more like Example 2 than Example 1. =A0Wha= t do you think?
>
> =A0 =A0 Karl
>
>
>
> =A0 =A0 On Sat, May 25, 2013 at 8:20 PM, Markus Schuch <markus_schuch@web.de
> =A0 =A0 <mailto:markus_schuch@web.de>> wrote:
>
> =A0 =A0 =A0 =A0 Hi Karl,
>
> =A0 =A0 =A0 =A0 no need to apologize... a response in less than 24 hou= rs to an open
> =A0 =A0 =A0 =A0 source project's mailing list entry is perfect to = me ;) - so thank you
> =A0 =A0 =A0 =A0 for the quick response and thank you for sacrificing y= our valuable
> =A0 =A0 =A0 =A0 holiday weekend time.
>
> =A0 =A0 =A0 =A0 The confluence API returns user and/or group names whe= n requesting
> =A0 =A0 =A0 =A0 permissions for a page.
>
> =A0 =A0 =A0 =A0 see:
> =A0 =A0 =A0 =A0 https://developer.atlassian.com/display/CONFDEV/Remote+Conflue= nce+Methods#RemoteConfluenceMethods-Permissions.1
> =A0 =A0 =A0 =A0 https://developer.atlassian.com/= display/CONFDEV/Remote+Confluence+Data+Objects#RemoteConfluenceDataObjects-= contentpermissionContentPermission
>
> =A0 =A0 =A0 =A0 But the API methods for retrieving page permissions do= not respect
> =A0 =A0 =A0 =A0 permissions inherited from parent pages which is very = sad. (refer to
> =A0 =A0 =A0 =A0 https://jira.atlassian.com/browse/CONF-14965)
>
> =A0 =A0 =A0 =A0 To workaround this problem we will have to write a con= fluence plugin
> =A0 =A0 =A0 =A0 that can give us the effective permissions for a page.=
> =A0 =A0 =A0 =A0 We looked into that and we think it is possible.
> =A0 =A0 =A0 =A0 In theory the effective page permissions retrieved by = our plugin would
> =A0 =A0 =A0 =A0 be a list of group names and/or usernames. The groupna= mes have to be
> =A0 =A0 =A0 =A0 ANDed to respect permissions inherited from parent pag= es. We can
> =A0 =A0 =A0 =A0 concatenate all needed combinations of group and user = names to single
> =A0 =A0 =A0 =A0 accesstokens to create a "flattened" version= of the permission
> =A0 =A0 =A0 =A0 hierarchy. So good so far...
>
> =A0 =A0 =A0 =A0 But another problem arises:
> =A0 =A0 =A0 =A0 The authority connector would also have to return acce= sstokens that are
> =A0 =A0 =A0 =A0 compatible to the flattened permission hierachy and th= erefore we must
> =A0 =A0 =A0 =A0 build all possible permutations of the user's grou= pnames. If our math is
> =A0 =A0 =A0 =A0 correct, there will be (2^n)-1 access tokens for a use= r (where n is the
> =A0 =A0 =A0 =A0 number of distinct groups the user is member of). Addi= tionally there
> =A0 =A0 =A0 =A0 will be more combinations with the username. This will= most probably not
> =A0 =A0 =A0 =A0 perform well for users with many group memberships. >
> =A0 =A0 =A0 =A0 I see these 2 options:
> =A0 =A0 =A0 =A0 - We could implement folder level accesstokens for a c= onstant number X
> =A0 =A0 =A0 =A0 of folder levels.
> =A0 =A0 =A0 =A0 So the outputconnector would need to reject documents = with a number of
> =A0 =A0 =A0 =A0 folder levels greater X.
> =A0 =A0 =A0 =A0 May be there is built in limit of page levels in confl= uence... if not,
> =A0 =A0 =A0 =A0 that this solution is not ideal.
> =A0 =A0 =A0 =A0 - Start to think about post filtering...
>
> =A0 =A0 =A0 =A0 Regards,
> =A0 =A0 =A0 =A0 Markus
>
> =A0 =A0 =A0 =A0 -----------------------------------------
>
> =A0 =A0 =A0 =A0 Gesendet: Samstag, 25. Mai 2013 um 16:54 Uhr
> =A0 =A0 =A0 =A0 Von: "Karl Wright" <daddywri@gmail.com <mailto:daddywri@gmail.com>>
> =A0 =A0 =A0 =A0 An: "user@manifoldcf.apache.org <mailto:user@manifoldcf.apache.org>"
> =A0 =A0 =A0 =A0 <user= @manifoldcf.apache.org <mailto:user@manifoldcf.apache.org>>
> =A0 =A0 =A0 =A0 Betreff: Re: How to map the atl= assian confluence security model to
> =A0 =A0 =A0 =A0 manifoldcf
>
> =A0 =A0 =A0 =A0 Hi Marcus,
>
> =A0 =A0 =A0 =A0 Sorry for the slow response - it is a holiday weekend = in the States, and
> =A0 =A0 =A0 =A0 that has managed to impact me to some degree.
> =A0 =A0 =A0 =A0 =A0Anyhow, I've looked at the doc on Atlassian sec= urity, and I have some
> =A0 =A0 =A0 =A0 questions. =A0First, when you call the Atlassian API, = and request security
> =A0 =A0 =A0 =A0 information for a document, in what form does it come = back? =A0If it comes
> =A0 =A0 =A0 =A0 back as a minimal list of groups and users which can s= ee the document,
> =A0 =A0 =A0 =A0 then you probably just want the access tokens for this= connector to be
> =A0 =A0 =A0 =A0 group names/ids and user names/ids. =A0If it is more c= omplicated, and
> =A0 =A0 =A0 =A0 basically you have to ascend the hierarchy either expl= icitly or
> =A0 =A0 =A0 =A0 implicitly, then we'll have to work a bit harder. = =A0Either we'll have to
> =A0 =A0 =A0 =A0 find a flat mapping of folders to access tokens, or we= 'll have to look
> =A0 =A0 =A0 =A0 at extending the framework to handle more stuff.
>
> =A0 =A0 =A0 =A0 As far as the folder-level security, the reason it is = deprecated at the
> =A0 =A0 =A0 =A0 moment is because it is very challenging to implement = properly in a
> =A0 =A0 =A0 =A0 standard search engine with a fixed schema, since ther= e are N possible
> =A0 =A0 =A0 =A0 folder parents, where N is determined by an individual= document.
> =A0 =A0 =A0 =A0 Furthermore, the model is not really applicable to the= case where there
> =A0 =A0 =A0 =A0 is a hierarchy that cannot be flattened. But, dependin= g on what the
> =A0 =A0 =A0 =A0 answer is to my question above, if needed we can try t= o come up with a
> =A0 =A0 =A0 =A0 workable folder implementation, and extend the Solr co= nnector and
> =A0 =A0 =A0 =A0 plugins as well.
>
> =A0 =A0 =A0 =A0 Karl
>
>
>
> =A0 =A0 =A0 =A0 On Fri, May 24, 2013 at 6:57 PM, Markus Schuch <markus_schuch@web.de
> =A0 =A0 =A0 =A0 <mailto:markus_schuch@web.de>> wrote:Hi,
>
> =A0 =A0 =A0 =A0 we are currently writing a repository connector for co= nfluence.
> =A0 =A0 =A0 =A0 We are using the solr output connection on Solr 4.x. > =A0 =A0 =A0 =A0 Seeding, versioning, processing works already and now = we have to face
> =A0 =A0 =A0 =A0 security.
>
> =A0 =A0 =A0 =A0 Compared to the already supported repositories by mcf,= confluence seems
> =A0 =A0 =A0 =A0 to have a different security model.
>
> =A0 =A0 =A0 =A0 There are "Space" permissions for a whole wi= ki space and these can
> =A0 =A0 =A0 =A0 easily be mapped as shareAllowTokens but there are als= o page
> =A0 =A0 =A0 =A0 restrictions. Page restrictions are attached to each p= age (page =3D
> =A0 =A0 =A0 =A0 document) and page restrictions are inherited.
>
> =A0 =A0 =A0 =A0 See "Example of Child Page Restrictions" in = the Confluence Doc:
> =A0 =A0 =A0 =A0 https://confluence.atlassian.com/display/DOC/Pa= ge+Restrictions[https://confluence.atlassian.com/display/DOC/Page+Restricti= ons]
> =A0 =A0 =A0 =A0 <https://confluence.atlassian.com/= display/DOC/Page+Restrictions%5Bhttps://confluence.atlassian.com/display/DO= C/Page+Restrictions%5D>
>
> =A0 =A0 =A0 =A0 The inheritance of page restrictions makes things diff= icult.
> =A0 =A0 =A0 =A0 If we are correct, than it is not sufficient to add th= e page
> =A0 =A0 =A0 =A0 restrictions as document level access tokens, because = the query time
> =A0 =A0 =A0 =A0 filtering handels the user's access tokens (e.g. g= roup memberships) as
> =A0 =A0 =A0 =A0 disjunction. Instead we probalby need a hierarchic, fo= lder based
> =A0 =A0 =A0 =A0 structure of access tokens to map the inheritance of t= he page
> =A0 =A0 =A0 =A0 restrictions correctly.
> =A0 =A0 =A0 =A0 The current Solr SearchComponent does not support fold= er level access
> =A0 =A0 =A0 =A0 tokens and the book (mcf in action) says, that these k= ind of tokens are
> =A0 =A0 =A0 =A0 considered deprecated.
> =A0 =A0 =A0 =A0 To cut a long story short... we are stuck at the momen= t.
>
> =A0 =A0 =A0 =A0 Our questions:
> =A0 =A0 =A0 =A0 Did anyone already manage to map confluence security t= o mcf/solr?
> =A0 =A0 =A0 =A0 Or does somebody has an idea how a confluence-like sec= urity model can be
> =A0 =A0 =A0 =A0 mapped to mcf/solr?
>
> =A0 =A0 =A0 =A0 Thanks in advance
> =A0 =A0 =A0 =A0 Markus
>
>
>

--001a11c2c010fbeccb04ddedcc2f--