Don, You seem to be suggesting that the UI be broken down into components that can be authorised independently. For example, a user who is allowed to query, but not to update, should not have access to UI elements (such as documents in its current incarnation) that allow updating. This is taking the UI further than I had considered, in this regard.
For myself, right now, I'm just keen to see that if authentication is required for Solr, then authentication will be required for the UI too. My suggestion to put the UI within a request handler or such was to facilitate the authentication framework interacting with it, e.g. having an admin-ui (or just a UI) role covering the whole UI. More sophisticated UIs are, for sure, possible, but I for one haven't thought that far yet. Upayavira On Sat, Nov 21, 2015, at 09:42 PM, Don Bosco Durai wrote: > 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 >
