[jira] [Commented] (SOLR-9702) Authentication & Authorization based on Jetty security
[ https://issues.apache.org/jira/browse/SOLR-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15620036#comment-15620036 ] Thomas Quinot commented on SOLR-9702: - I see, thanks for the explanations! I guess this issue could be usefully reformulated into an actionable one by making it a suggestion for a Solr Auth/Authz plugin based on JAAS. We'd thus get a variety of backend options (including LDAP) for a single one-time development effort. > Authentication & Authorization based on Jetty security > -- > > Key: SOLR-9702 > URL: https://issues.apache.org/jira/browse/SOLR-9702 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Affects Versions: 6.2.1 >Reporter: Thomas Quinot > > (following up on comments initially posted on SOLR-7275). > Back in Solr 4 days, user authentication could be handled by Jetty, and some > level of authorization could be implemented using request regexp rules. This > was explicitly documented in the SolrSecurity page: > http://wiki.apache.org/solr/SolrSecurity?action=recall&rev=35#Jetty_realm_example > In particular, authentication could thus be performed against a variety of > services implemented in Jetty, such as HashLoginService (mentioned explicitly > in the above documentation, tested in production, does work) or possibly > JAASLoginService, which in turn would open up the possibility to use a whole > range of auth services (in particular LDAP servers). > I see that the usage of Jetty is now "an implementation detail". Does this > mean that the feature listed above is not supported anymore? (This is quite > unfortunate IMO, as even just the HashLoginService would be useful to > authenticate users against a database of UNIX crypt(3) passwords) > The new login services that are apparently being reimplemented in Solr itself > seem to be much less flexible and limited. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9702) Authentication & Authorization based on Jetty security
Thomas Quinot created SOLR-9702: --- Summary: Authentication & Authorization based on Jetty security Key: SOLR-9702 URL: https://issues.apache.org/jira/browse/SOLR-9702 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: security Affects Versions: 6.2.1 Reporter: Thomas Quinot (following up on comments initially posted on SOLR-7275). Back in Solr 4 days, user authentication could be handled by Jetty, and some level of authorization could be implemented using request regexp rules. This was explicitly documented in the SolrSecurity page: http://wiki.apache.org/solr/SolrSecurity?action=recall&rev=35#Jetty_realm_example In particular, authentication could thus be performed against a variety of services implemented in Jetty, such as HashLoginService (mentioned explicitly in the above documentation, tested in production, does work) or possibly JAASLoginService, which in turn would open up the possibility to use a whole range of auth services (in particular LDAP servers). I see that the usage of Jetty is now "an implementation detail". Does this mean that the feature listed above is not supported anymore? (This is quite unfortunate IMO, as even just the HashLoginService would be useful to authenticate users against a database of UNIX crypt(3) passwords) The new login services that are apparently being reimplemented in Solr itself seem to be much less flexible and limited. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15618615#comment-15618615
]
Thomas Quinot commented on SOLR-7275:
-
SOLR-9702 created.
> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
> Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and
> return an {{SolrAuthorizationResponse}} object. The object as of now would
> only contain a single boolean value but in the future could contain more
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to
> understand Solr's capabilities e.g. how to extract the name of the collection
> or other information from the incoming request as there are multiple ways to
> specify the target collection for a request. Similarly request type can be
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
> public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public class SolrRequestContext {
> UserInfo; // Will contain user context from the authentication layer.
> HTTPRequest request;
> Enum OperationType; // Correlated with user roles.
> String[] CollectionsAccessed;
> String[] FieldsAccessed;
> String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
> boolean authorized;
> public boolean isAuthorized();
> }
> {code}
> User Roles:
> * Admin
> * Collection Level:
> * Query
> * Update
> * Admin
> Using this framework, an implementation could be written for specific
> security systems e.g. Apache Ranger or Sentry. It would keep all the security
> system specific code out of Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15618593#comment-15618593
]
Thomas Quinot commented on SOLR-7275:
-
Thanks for your feedback Paul. I will open a separate issue for followup
discussion.
> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
> Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and
> return an {{SolrAuthorizationResponse}} object. The object as of now would
> only contain a single boolean value but in the future could contain more
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to
> understand Solr's capabilities e.g. how to extract the name of the collection
> or other information from the incoming request as there are multiple ways to
> specify the target collection for a request. Similarly request type can be
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
> public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public class SolrRequestContext {
> UserInfo; // Will contain user context from the authentication layer.
> HTTPRequest request;
> Enum OperationType; // Correlated with user roles.
> String[] CollectionsAccessed;
> String[] FieldsAccessed;
> String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
> boolean authorized;
> public boolean isAuthorized();
> }
> {code}
> User Roles:
> * Admin
> * Collection Level:
> * Query
> * Update
> * Admin
> Using this framework, an implementation could be written for specific
> security systems e.g. Apache Ranger or Sentry. It would keep all the security
> system specific code out of Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617430#comment-15617430
]
Thomas Quinot commented on SOLR-7275:
-
Back in the time of Solr 4, it was possible to control access using the Java
security service, loading LoginService modules provided by Jetty. For example
Infosys
/myapp/auth/webauth.properties
allowed user authentication against a list of UNIX crypt(3) hashes.
Is this officially gone? If so this seems to be a significant regression.
If this is still supported, could the
org.ecliporg.eclipse.jetty.plus.jaas.JAASLoginService class be added to the
Jetty instance packaged with Solr? JAAS provides a lot of flexibility without
requiring Solr to reinvent the wheel (for example allowing authentication
against an LDAP server).
> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
> Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch,
> SOLR-7275.patch, SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and
> return an {{SolrAuthorizationResponse}} object. The object as of now would
> only contain a single boolean value but in the future could contain more
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to
> understand Solr's capabilities e.g. how to extract the name of the collection
> or other information from the incoming request as there are multiple ways to
> specify the target collection for a request. Similarly request type can be
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
> public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public class SolrRequestContext {
> UserInfo; // Will contain user context from the authentication layer.
> HTTPRequest request;
> Enum OperationType; // Correlated with user roles.
> String[] CollectionsAccessed;
> String[] FieldsAccessed;
> String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
> boolean authorized;
> public boolean isAuthorized();
> }
> {code}
> User Roles:
> * Admin
> * Collection Level:
> * Query
> * Update
> * Admin
> Using this framework, an implementation could be written for specific
> security systems e.g. Apache Ranger or Sentry. It would keep all the security
> system specific code out of Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
