[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107413#comment-13107413
]
Karl Wright commented on SOLR-1895:
-----------------------------------
I think your expectation for s-d13 may be incorrect. If you use AD as a model,
you are effectively applying share security that has no allow sids but some
deny sids. With AD you would not get this doc either.
-----Original Message
-----
From: ext Koji Sekiguchi (JIRA)
Sent: 17/09/2011, 11:49 PM
To: dev@lucene.apache.org
Subject: [jira] [Issue Comment Edited] (SOLR-1895) ManifoldCF SearchComponent
plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107329#comment-13107329
]
Koji Sekiguchi edited comment on SOLR-1895 at 9/18/11 3:47 AM:
---------------------------------------------------------------
I figured out why the test doesn't pass. In this test, I provided the following
documents:
{code}
// | share | document
// |--------------|--------------
// | allow | deny | allow | deny
// ---------+-------+------+-------+------
// d-a12 | | | 1, 2 |
// ---------+-------+------+-------+------
// d-a1-d3 | | | 1 | 3
// ---------+-------+------+-------+------
// s-d13 | | 1, 3 | |
// ---------+-------+------+-------+------
// ds-a23-d1| 3 | 1 | 2 |
// ---------+-------+------+-------+------
// notoken | | | |
// ---------+-------+------+-------+------
{code}
and when querying "**:**" with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
was (Author: koji):
I figured out why the test doesn't pass. In this test, I provided the
following documents:
{code}
// | share | document
// |--------------|--------------
// | allow | deny | allow | deny
// ---------+-------+------+-------+------
// d-a12 | | | 1, 2 |
// ---------+-------+------+-------+------
// d-a1-d3 | | | 1 | 3
// ---------+-------+------+-------+------
// s-d13 | | 1, 3 | |
// ---------+-------+------+-------+------
// ds-a23-d1| 3 | 1 | 2 |
// ---------+-------+------+-------+------
// notoken | | | |
// ---------+-------+------+-------+------
{code}
and when querying "*:*" with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
> ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
> time
> ----------------------------------------------------------------------------------
>
> Key: SOLR-1895
> URL: https://issues.apache.org/jira/browse/SOLR-1895
> Project: Solr
> Issue Type: New Feature
> Components: SearchComponents - other
> Reporter: Karl Wright
> Labels: document, security, solr
> Fix For: 3.5, 4.0
>
> Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
> LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
> SOLR-1895.patch, SOLR-1895.patch
>
>
> I've written an LCF SearchComponent which filters returned results based on
> access tokens provided by LCF's authority service. The component requires
> you to configure the appropriate authority service URL base, e.g.:
> <!-- LCF document security enforcement component -->
> <searchComponent name="lcfSecurity" class="LCFSecurityFilter">
> <str
> name="AuthorityServiceBaseURL">http://localhost:8080/lcf-authority-service</str>
> </searchComponent>
> Also required are the following schema.xml additions:
> <!-- Security fields -->
> <field name="allow_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="allow_token_share" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_share" type="string" indexed="true" stored="false"
> multiValued="true"/>
> Finally, to tie it into the standard request handler, it seems to need to run
> last:
> <requestHandler name="standard" class="solr.SearchHandler" default="true">
> <arr name="last-components">
> <str>lcfSecurity</str>
> </arr>
> ...
> I have not set a package for this code. Nor have I been able to get it
> reviewed by someone as conversant with Solr as I would prefer. It is my
> hope, however, that this module will become part of the standard Solr 1.5
> suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
