[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115967#comment-13115967
]
Karl Wright commented on SOLR-1895:
-----------------------------------
bq. * Does ManifoldCF security component support arbitrary security model or
it's just about Windows AD?
The short answer is, "no"; it is not just about Windows AD. ManifoldCF
supports AD, FileNet, Documentum, LiveLink, and Meridio authorization as well,
and others get added periodically.
It might help for you to read up on ManifoldCF. There's a book
(http://www.manning.com/wright); you'd want to read Chapters 4 and 8. I can
email them to you if you give me a preferred email address. I will also be
presenting in Barcelona in a month on this topic.
bq. * What's token_share? How is it different from token_document?
In order to be able to support AD, ManifoldCF allows multiple levels of token.
There are allow/deny tokens for "share" level (which correspond in AD to
Windows shares), "document" level (which correspond to windows documents), and
also N folder levels (which don't appear in Solr because the ManifoldCF Solr
output connector won't accept documents that have security set on those).
Share and document security operate completely independently of one another,
but a document cannot be viewed unless it is allowed (and not denied) on BOTH
levels.
bq. * It seems that under the hood it generates "deny overrides allow" type
of query. But I'm not sure that it is always the case, because afaiu the order
of Access Control Entries (ACE) in Access Control List (ACL) is important.
That is actually not the case. This was tested extensively at MetaCarta
in-house; there is no order dependency in AD or any other ManifoldCF-supported
repository.
> 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-queries.patch,
> SOLR-1895-queries.patch, SOLR-1895-queries.patch, SOLR-1895-queries.patch,
> SOLR-1895-service-plugin.patch, SOLR-1895-service-plugin.patch,
> SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
