You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2010/04/28 23:34:04 UTC
[jira] Created: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
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
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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862193#action_12862193 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
>>>>>>
Given that search requests are http-based, how would this be done, in say, an intranet environment?
<<<<<<
The usual way is to configure the application server running solr to either use certificate authentication (which requires the connecting client to be able to identify themselves via a secure cert), or if on a Unix box, configure the application server to not accept connections from (say) anything other than the localhost adapter.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Peter Sturge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862206#action_12862206 ]
Peter Sturge commented on SOLR-1895:
------------------------------------
{quote}
The usual way is to configure the application server running solr to either use certificate authentication (which requires the connecting client to be able to identify themselves via a secure cert)
{quote}
Yes, cert authentication is a good way to go, but once you've got one (because you have at least some privileges), you can by bypass the lower-layer doc security because you've already done the cert auth.
{quote}
configure the application server to not accept connections from (say) anything other than the localhost adapter.
{quote}
I don't understand how localhost-only would give you any access off the box.
I guess what I meant was, your client is wherever your client is, and this client could (and probably would) have a web browser installed. If a bona-fide user was an IT Operator, it would be easy for him/her to 'pretend' to be an HR Manager, unless some kind of post-login identity check prevents it.
One way 'round this is to encrypt part or all of the http parameters (essentially, this is what the hash mechanism does in SOLR-1872).
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Peter Sturge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862225#action_12862225 ]
Peter Sturge commented on SOLR-1895:
------------------------------------
That makes total sense to keep a proxy app separate.
Why wouldn't users interact with Solr directly? There's a lot of client-side stuff available to do just that. I wouldn't have thought there are too many implementations out there that completely block Solr http read access, because this would break replication, distributed searching, spell checkers, custom handlers etc. Generally, web proxies and firewalls etc. do a good job on this side of things, which is one of the reasons doc-level security is such a tricky business - you have to let traffic through and restrict it in solr.war that you would normally not let anywhere near Solr.
You're right that /update, /admin etc. need to be 'locked-down', but this is quite strightforward, so as not to allow users access to write or change anything.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862140#action_12862140 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
One thing I forgot in the original description...
The plug-in looks for an authenticated user name in the input argument "AuthenticatedUserName", which should be in the form 'user@domain' if this is an AD user. If no such argument is found, the plug-in allows only open documents to be returned (that is, those that have no security whatsoever). Note that the plug-in makes no attempt whatsoever to authenticate the user; that is presumed to take place at another level.
> 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
[jira] Updated: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright updated SOLR-1895:
------------------------------
Attachment: LCFSecurityFilter.java
Another revision that explicitly uses ConstantScoreQuery and filters to guarantee no scoring effects (and no max boolean clause problems).
> 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
[jira] Updated: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright updated SOLR-1895:
------------------------------
Attachment: LCFSecurityFilter.java
Updated version, using getFilters() and setFilters(), which seems resilient about where it is placed in the execution chain.
> 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
>
>
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Peter Sturge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862150#action_12862150 ]
Peter Sturge commented on SOLR-1895:
------------------------------------
It's worth bearing in mind that more than just a username is required in the input in order to ensure secure access. Otherwise, security is compromised simply by guessing (or already knowing) the username of someone with higher privileges.
For example:
User Dishwasher has low privileges
User Admin has high privileges
When Dishwasher logs in, all he/she has to do is put Admin's name in the input argument, and has now assumed Admin's rights.
User Admin doesn't need to be logged in for this to happen.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Anders Rask (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862624#action_12862624 ]
Anders Rask commented on SOLR-1895:
-----------------------------------
Hi Karl!
This looks very good. But it seems like a lot of double work between this search component and the search component that I develop in SOLR-1834. With my module we would also get a framework for enforcing different security models for different sources.
I propose this:
We cooperate to make a binding between my security component and LCF. As I see it I could use this code to implement a security provider (what I call a module that collects groups from a security source e.g. AD) that collects groups through the LCF framework from the underlying sources. And then we can cooperate to implement security models (what I call a module that enforces security in a manner consistent with that of the underlying source) for the sources supported by the LCF framework.
How do you feel about this?
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862643#action_12862643 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
Hi Anders,
Indeed, I based some of the code in this ticket on code you had contributed in SOLR-1834.
If we cooperate, I would suggest that we take the time and effort to understand both SOLR-1834 and LCF, thoroughly. It is not clear from your comments that you are familiar with the LCF security model - which to me seems to have many of the same concepts as your offering, but built as part of an extensible crawling framework. If you want to become more familiar with LCF, I suggest that you start here, and look especially into the "Concepts and Terminology" link.
http://incubator.apache.org/connectors/developer-resources.html
I think I have a good idea of the code in SOLR-1834, but obviously I cannot read your intent, and how you would anticipate system integrators make use of this proposal. If you would like to clarify, please provide some use cases (e.g. reasonably detailed scenarios) so that I'm sure we are both on the same page. ;-)
Thanks,
Karl
> 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
[jira] Updated: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright updated SOLR-1895:
------------------------------
Attachment: LCFSecurityFilter.java
Added the ability to work with the LCF mod_authz_annotate Apache2 plugin, as an alternate model. In this model, if the AuthenticatedUserName parameter is not present, the Search Component looks for a UserTokens array of parameters instead.
Right now, mod_authz_annotate puts the requisite tokens into the AAAGRP header. Since it doesn't appear to be possible for Search Components to be able to get at http request headers directly, it will be up to the user's web application to read the contents of the AAAGRP header and form those into UserTokens parameters when requesting results from Solr.
> 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, 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Peter Sturge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862215#action_12862215 ]
Peter Sturge commented on SOLR-1895:
------------------------------------
Right, ok, so you're using a proxy app to 'shield' the Solr http. Yes, that will work well for user searches. Sorry, I didn't see this app in the jira post.
For replication, distributed searches, spell checkers etc., I guess these could also go through the proxy app as well - the app would need to support all those mechanisms.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862219#action_12862219 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
There's no "proxy app" in the jira post because I obviously didn't provide an end-user application to go along with Solr. I expect that end-users will not be interacting with Solr directly anyway, since it provides mainly API-level access but not much end-user-friendly access, other than administration, which you probably don't want end-users to be able to do either. And finally, allowing access to the update/delete API to end users is a huge security hole all by itself.
So, granted there is another application involved, it's going to need to do several things:
(0) Present itself appropriately in the end-user environment
(1) Authenticate the end-user
(2) Submit requests to Solr in proper form
> 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
[jira] Updated: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright updated SOLR-1895:
------------------------------
Attachment: LCFSecurityFilter.java
Original grant of source code for LCFSecurityFilter.
> 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
>
>
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862178#action_12862178 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
>>>>>>
Otherwise, security is compromised simply by guessing (or already knowing) the username of someone with higher privileges.
<<<<<<
That is obviously true, so anyone setting up such a system would not want the Solr webapp to be accessible by just anyone. The presumption is that the Solr webapp is not the final user interface, and is indeed not accessible to the user at all. This problem is generally addressed by controlling exactly who can connect to the Solr socket.
But also bear in mind that the following "security holes" exist, and need to be dealt with appropriately:
(1) The index files themselves contain potentially secure data;
(2) solrconfig.xml can be changed to point to a spoofed authority service.
So, in general, locking the box down that runs Solr is the only way to go.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Peter Sturge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862191#action_12862191 ]
Peter Sturge commented on SOLR-1895:
------------------------------------
>>>>>>
The presumption is that the Solr webapp is not the final user interface, and is indeed not accessible to the user at all.
<<<<<<
Given that search requests are http-based, how would this be done, in say, an intranet environment? I agree that a user interface wouldn't expose any means to change the http parameters, but if http is available to the UI, it'll also be available to a web browser's search bar at the same station (unless some tunnelling, proxy or similar is used).
Totally agree on the server lock down - hopefully, everyone does this already as a matter of course!
There are a couple of ways to address the impersonator problem. Probably the most robust way is to use SSL authentication from client to container, then have the Solr app integrate with the container (like we talked about for the authentication piece) and use its session certificate to ensure that any requests coming from the remote station match those of the originally authenticated user.
A somewhat easier method is to use the hash and session id mechanism used in SOLR-1872. This provides pgp protection for stopping impersonation (even gaining any access from a browser), but wouldn't be suitable outside of an intranet environment (for exposed internet access, it would really need to be SSL - for sensitive data, though, you wouldn't expect it to be exposed across a DMZ anyway).
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862210#action_12862210 ]
Karl Wright commented on SOLR-1895:
-----------------------------------
>>>>>>
I don't understand how localhost-only would give you any access off the box.
<<<<<<
You would not give any access to the port that Solr is running on off-box. That's the whole point. The presumption would be that another end-user-friendly application would be running on some other port on the same box, and it would talk to solr via the loop-back adapter. To repeat, nothing off-box should be able to get to Solr directly.
> 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (SOLR-1895) LCF SearchComponent plugin for
enforcing LCF security at search time
Posted by "Anders Rask (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org