lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1895) LCF SearchComponent plugin for enforcing LCF security at search time
Date Wed, 05 May 2010 22:06:03 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864551#action_12864551
] 

Karl Wright commented on SOLR-1895:
-----------------------------------

>>>>>>
You are talking about an "Active Directory authorization model", what do you mean by this?
<<<<<<

I meant the combination of a user have user/group SIDs, and files, folders, shares or other
entities having access rights based on those SIDs.

>>>>>>
....in Documentum a group might be used in it's concept of rooms...
<<<<<<

Yes, of course, this would represent the basic concept of abstraction.

I understand that SOLR-1834 tries to introduce an abstraction at this level.  What I don't
understand yet is how this differs from what LCF already provides (and provides in a complete
and thoroughly tested manner, for some dozen kinds of repository).   I remember that SOLR-1834
uses access-token-based filters to control access, and uses an interface called IRepository
to get a user's access tokens, but I don't recall where it gets the access tokens attached
to the documents?



> LCF SearchComponent plugin for enforcing LCF 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
>             Fix For: 1.5
>
>         Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java, LCFSecurityFilter.java
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message