drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@apache.org>
Subject Re: [drill] Web UI Security (0a01dfd)
Date Fri, 04 Sep 2015 15:56:48 GMT
Adding Dev, which somehow got dropped off.

On Fri, Sep 4, 2015 at 8:56 AM, Jacques Nadeau <jacques@apache.org> wrote:

> My main concern is that we're recreating an authorization management
> model. It looks like Jetty has a LoginService approach which would then
> integrate with its authorization capabilities around roles/realms/etc.  We
> also can also then use Servlet 3.x's annotation based security to ensure
> compliance.
> On Thu, Aug 27, 2015 at 9:18 AM, Venki Korukanti <
> venki.korukanti@gmail.com> wrote:
>> Hi Jacques,
>> I am looking into details of inbuilt security capabilities in jetty and
>> jersey. If I understand correctly following are the approaches I found:
>>    1. Add a SecurityHandler (which in turn could include
>>    FormAuthenticator, LoginService and ConstraintMapping) to
>>    ServletContextHolder.
>>    2. Add custom RolesAllowedResourceFilterFactory and ResourceFilter implementations
>>    which creates a custom SecurityContext implementation and User details
>>    (isUserInRole methods). We could add roles annotation to rest methods to
>>    control authorization.
>> These approaches again seems to be reimplementing the same authentication
>> or authorization code we use in DrillClient.
>> I am wondering whether you have some time (mostly may take 15mins) to
>> discuss these over a hangout.
>> Thanks
>> Venki
>> On Fri, Aug 21, 2015 at 6:05 PM, Jacques Nadeau <notifications@github.com
>> > wrote:
>>> It really seems like this should be three separate proposed commits.
>>> Here are some high level comments on each:
>>>    -
>>>    Add SSL to WebUI
>>>    I'm inclined to switch Drill's default to always doing SSL. We can
>>>    do this by using a self-signed cert rather than having to configure a trust
>>>    store. If someone wants to control the server cert, then they would have to
>>>    configure a trust store.
>>>    -
>>>    Make Rest API methods all use DrillClient
>>>    As discussed above, I don't think we should be creating a large
>>>    number of additional RPC wire protocol items. We should continue the
>>>    existing pattern of minimizing API surface and using SQL for operations.
>>>    These operations are all things that people have also requested via SQL.
>>>    This allows us to have only one entry point for that code instead of
>>>    multiple.
>>>    -
>>>    Add WebUI Authentication
>>>    We need to have a design discussion on JIRA around the method to
>>>    securing the WebUI calls. It seems like we're implementing a custom way to
>>>    manage security around web requests (including the use of a customer filter
>>>    and BaseModel. There are a number of standard ways to provide this
>>>    functionality that will probably be much easier to maintain and more
>>>    secure. For example Jersey has some built in capabilities. There is also a
>>>    bunch of capabilities built into servlets and jetty around security
>>>    constraints and context. Especially for security, I'm inclined to use
>>>    pre-existing solutions rather than implementing custom solutions.
>>> —
>>> Reply to this email directly or view it on GitHub
>>> <https://github.com/vkorukanti/drill/commit/0a01dfdbe7bfe40a4f63a9dfbfdaaeb0d7830329#commitcomment-12840456>
>>> .

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message