>You seem to be suggesting that the UI be broken down into components that can >be authorised independently. Yes, this is what I was mostly concerned of. It doesn’t apply much with today’s Admin UI though...
>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. I agree with you, if it is just authentication for the current admin UI and if authentication is enabled, then we should just authenticate all requests. Because in HTTP, authentication is just done once and the session cookie is used for subsequent requests. So this is an extremely low (no cost) operation. When I tested Solr with Kerberos, that is how it was already working. If you don’t have not done “knit” on your local machine, you can’t access any page. If you are done kinit, then you can access the pages, but most of the stuff will not work, because you don’t make the call to get the required data. So, if you can the person the permission for action “sol_admin”, then everything should work. I have not tested BASIC auth implementation yet. So can’t speak for it. But the underlying design/implementation should be the same. Unless something changed from when I originally tested just before 5.2 was released. Bosco On 11/22/15, 12:45 PM, "Upayavira" <u...@odoko.co.uk> wrote: >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 >>
