In traditional web interface application, the URLs can be configured as
public->authenticated->authorized. Which is very similar to what you are
suggesting.
>I tried out BasicAuthPlugin today. Surprised that not admin UI is protected.
My suggestion would be to differentiate between Web Interface and HTTP API
interfaces. Because trying to solve both using the same design will not be very
easy and even if you do it, it will be management nightmare.
>I'm very happy for the admin UI to be served another way - i.e. Not direct
>from Jetty, if that makes the task of securing it easier.
Do you see a richer Solr UI? My understanding on talking with Anshum (offline)
was that the Solr Admin UI was only for Admin Users. So technically you need to
have “all” permission to access the Solr Admin UI. Which I think is a fair
point.
If we are planning to give an alternate UI. Then your point is valid and it
gives more framework options to choose from. Traditional web interfaces mostly
deal with static pages and servlet/REST requests to get data from the server.
Frameworks like Spring give a lot of control how you want to configure these
URLs. I know we are trying to get out of Jetty and Tomcat. But frameworks like
Spring make life a lot easier when you are dealing with Web Interfaces. It can
also support different authentication schemes for WebUI. I feel, instead of
reinventing the wheel here, we should consider some framework which will give
Web Interface level access control and authentication.
For the APIs (/select, /query, etc…), I feel, the current design is pretty
flexible. Of course, we should make sure all access path are controlled and
easy to manage.
>Take the well-known permission “read” for instance. It protects /select and
>/get. But it won’t protect /query, /browse, /export, /spell, /suggest, /tvrh,
>/terms, /clustering or /elevate, all which also expose sensitive info.
Apache Ranger does one of the implementation for the Solr authorizer interface.
In 5.2, we supported the following actions:
public static final String ACCESS_TYPE_CREATE = "create";
public static final String ACCESS_TYPE_UPDATE = "update";
public static final String ACCESS_TYPE_QUERY = "query";
public static final String ACCESS_TYPE_OTHERS = "others";
public static final String ACCESS_TYPE_ADMIN = "solr_admin";
My assumptions was that the other actions will map to one of these. E.g.
/suggest will map to “query” and “/export” will map to “solr_admin”. My
assumptions might be incorrect. But we mapped all unknown/non-standard actions
to “others”. I will review the code to see if I missed anything.
Bosco
On 11/20/15, 2:27 PM, "Jan Høydahl" <jan....@cominvent.com> wrote:
>> ideally we should have a simple permission name called "all" (which we
>> don't have)
>>
>> so that one rule should be enough
>>
>> "name":"all",
>> "role":"somerole"
>>
>> Open a ticket and we should fix it for 5.4.0
>> It should also include the admin paths as well
>
>Yes, that would be convenient.
>
>I still don’t like the existing "open-by-default” security mode of Solr. It is
>very fragile to mis-configuration without people noticing. Take the well-known
>permission “read” for instance. It protects /select and /get. But it won’t
>protect /query, /browse, /export, /spell, /suggest, /tvrh, /terms, /clustering
>or /elevate, all which also expose sensitive info.
>
>How about allowing to choose between three different security modes?
>
>-Dsolr.security.mode=open : As today - paths not configured are wide
>open
>-Dsolr.security.mode=authenticated : Paths not configured are open to any
>authenticated user
>-Dsolr.security.mode=explicit : Paths not configured are closed to all.
>All acccess is explicitly configured
>
>/Jan
