Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

I see. Would it rather make sense to hide "shiro-or-else" decision behind a light interface instead? Something along the lines of the existing SessionValidator.checkAuthorized() that would accept a wrapper object with all necessary security data. On Wed, Feb 11, 2015 at 4:20 PM, Kevin Sweeney wro

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

I'm proposing more-or-less the "if SHIRO_ENABLED do shiro_auth else do old_stuff" approach so that the SHIRO_ENABLED branch can throw UnsupportedOperationException for a period of time. On Wed, Feb 11, 2015 at 4:14 PM, Maxim Khutornenko wrote: > Right, I was asking about an example of the interi

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

Right, I was asking about an example of the interim incremental approach you are proposing. Are you envisioning something like "if SHIRO_ENABLED do shiro_auth else do old_stuff" approach? The example you gave shows the end result not what we will see in 0.8.0 (unless you are suggesting moving "old_

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

I think that would be too big a patch to land all at once. I'd like to add in Shiro permission checks and annotations incrementally behind this flag as there are conceptually different changes that will benefit from small reviews. If I take the approach of ripping out the current framework first we

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

Sounds good! On Wed, Feb 11, 2015 at 3:57 PM, Kevin Sweeney wrote: > I'm thinking that flag will control which Guice bindings are applied, so > there would be 2 parallel implementations for a bit. This would necessitate > factoring out capabilityValidator calls to a decorator class (or risk > ha

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

Any example? The original code fragment suggest our current security model does not map cleanly into shiro. I am +1 on the first pass to reduce the "if-else" ugliness if possible. On Wed, Feb 11, 2015 at 3:57 PM, Kevin Sweeney wrote: > I'm thinking that flag will control which Guice bindings are

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

I'm thinking that flag will control which Guice bindings are applied, so there would be 2 parallel implementations for a bit. This would necessitate factoring out capabilityValidator calls to a decorator class (or risk having #ifdef-like logic everywhere in SchedulerThriftInterface). On Wed, Feb 1

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

How do you envision things looking in the intermediate phase where we have support for both security modes? I imagine it's easy enough on the Shiro side of if we go with the AOP annotations for authorization (the interceptor can just check if security_mode == SHIRO before doing anything), but that

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

On Wed, Feb 11, 2015 at 3:19 PM, Zameer Manji wrote: > +1 to this proposal. > > Will we have dual implementations of API methods as we deprecate the > SessionKey based API methods? > Yes for backwards-compatibility I think we'll need a flag to indicate which system to use. It will probably be an

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

+1 to this proposal. Will we have dual implementations of API methods as we deprecate the SessionKey based API methods? On Wed, Feb 11, 2015 at 3:13 PM, Kevin Sweeney wrote: > I've been thinking about revamping the authentication and authorization in > the scheduler recently. I've investigated

[DISCUSS] Use the Apache Shiro framework for scheduler security

I've been thinking about revamping the authentication and authorization in the scheduler recently. I've investigated Apache Shiro and I think it would fit into the scheduler nicely as a replacement for our custom CapabilityValidator