[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864473#action_12864473
]
Anders Rask commented on SOLR-1895:
-----------------------------------
You are right, it would be beneficial if we first have a clear understanding of
both SOLR-1834 and LCF.
I have read through the links that you gave me and I have some thoughts:
You are talking about an "Active Directory authorization model", what do you
mean by this?
To my understanding Active Directory is a directory service where you can store
certain types of objects for example groups and users, but it is up to the data
source how to use these objects in it's security model.
In NTFS for example; belonging to a group might mean that you get access to a
document or that you don't get access to a document because it might be a deny
right set on it.
But on the other hand; in Documentum a group might be used in it's concept of
rooms. Stating that a user must first be a member of a certain group to get
access to the "room of documents", but must then also be a member of another
group to read a certain document in the room.
This is where my concept of different security models for different sources
comes in. For my security component to work you must know what source a
document comes from. This source is then correlated to a security model in the
solrconfig file. The security model will get the groups from the security
provider (which in this case will get them from LCF) and use them in such a way
that it emulates the security in the source.
Does this make it clear what a security model is in the context of SOLR-1834?
PS
I should be clear right now and say that the Documentum model in my component
is in no way a complete model.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
