aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Khutornenko <ma...@apache.org>
Subject Re: [DISCUSS] Use the Apache Shiro framework for scheduler security
Date Thu, 12 Feb 2015 00:03:14 GMT
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 <kevints@apache.org> 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
> having #ifdef-like logic everywhere in SchedulerThriftInterface).
>
> On Wed, Feb 11, 2015 at 3:49 PM, Joshua Cohen <jcohen@twopensource.com>
> wrote:
>
>> 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 means we'd still
>> have the legacy sessionValidator code in every RPC impl that would need to
>> be wrapped in the inverse check (security_mode == CAPABILITY_VALIDATOR).
>>
>> Would it make sense to do a first pass to refactor the existing auth
>> checking logic to a reusable method, or are we ok living with the temporary
>> ugliness involved in adding that mode checking wrapper to all the existing
>> auth code?
>>
>> On Wed, Feb 11, 2015 at 3:23 PM, Kevin Sweeney <kevints@apache.org> wrote:
>>
>> > On Wed, Feb 11, 2015 at 3:19 PM, Zameer Manji <zmanji@apache.org> 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 all-or-nothing setting (think
>> > -security_mode=SHIRO|CAPABILITY_VALIDATOR).
>> >
>> > >
>> > > On Wed, Feb 11, 2015 at 3:13 PM, Kevin Sweeney <kevints@apache.org>
>> > wrote:
>> > >
>> > > > I've been thinking about revamping the authentication and
>> authorization
>> > > in
>> > > > the scheduler recently. I've investigated Apache Shiro
>> > > > <http://shiro.apache.org/> and I think it would fit into the
>> scheduler
>> > > > nicely as a replacement for our custom CapabilityValidator
>> > > > <
>> > > >
>> > >
>> >
>> http://people.apache.org/~kevints/aurora/dist/0.5.0-incubating/javadoc/org/apache/aurora/auth/CapabilityValidator.html
>> > > > >
>> > > > framework (for which there currently exists no implementation).
>> > > >
>> > > > I'd like feedback on this proposal.
>> > > > Status Quo
>> > > >
>> > > > Security is currently implemented by a hand-rolled SessionValidator
>> > > > <
>> > > >
>> > >
>> >
>> http://people.apache.org/~kevints/aurora/dist/0.5.0-incubating/javadoc/org/apache/aurora/auth/SessionValidator.html
>> > > > >
>> > > > framework. No public implementations exist.
>> > > > Proposal
>> > > >
>> > > > Change the scheduler to use the Apache Shiro framework for
>> > authentication
>> > > > and authorization. Move authentication from application to transport
>> > > layer
>> > > > and move authorization to the Shiro Permissions model.
>> > > > Advantages
>> > > >
>> > > > A few things that will become possible once this work is complete:
>> > > >
>> > > > 1. Ability to configure secure Aurora client-to-scheduler with a
>> simple
>> > > > flat configuration file (shiro.ini
>> > > > <http://shiro.apache.org/configuration.html>).
>> > > >
>> > > > 2. Ability to integrate Aurora with my enterprise SSO (Kerberos+LDAP
>> > for
>> > > > example) by implementing a custom Shiro Realm
>> > > > <http://shiro.apache.org/realm.html>.
>> > > >
>> > > > 3. Ability to allow a CI server to continuously deploy to every
>> role's
>> > > > "staging" environment without being able to touch its "prod" one by
>> > using
>> > > > Shiro's WildcardPermission
>> > > > <
>> > > >
>> > >
>> >
>> https://shiro.apache.org/static/1.2.3/apidocs/org/apache/shiro/authz/permission/WildcardPermission.html
>> > > > >
>> > > > .
>> > > >
>> > > > 4. Ability to authenticate to the scheduler API using Kerberos (via
>> > > SPNEGO
>> > > > <http://spnego.sourceforge.net/>) or HTTP Basic auth.
>> > > >
>> > > > 5. Ability to perform authenticated write operations on a job via
the
>> > web
>> > > > UI
>> > > > <
>> > http://www.chromium.org/developers/design-documents/http-authentication
>> > > >.
>> > > > Suggested Reading
>> > > >
>> > > > Shiro has excellent documentation and is a fellow Apache Foundation
>> > > > project. I suggest you check out at least the 10-minute tutorial
>> > > > <http://shiro.apache.org/10-minute-tutorial.html> and the Guice
>> > > > integration
>> > > > documentation <http://shiro.apache.org/guice.html>.
>> > > > Scheduler-side changes
>> > > >
>> > > > The best way to show the proposed changes is by example. In addition
>> to
>> > > > Guice wiring changes to place the Shiro authentication filter into
>> the
>> > > > request chain, code that previously looked like
>> > > >
>> > > >  @Override
>> > > >
>> > > >  public Response createJob(
>> > > >
>> > > >      JobConfiguration mutableJob,
>> > > >
>> > > >      @Nullable final Lock mutableLock,
>> > > >
>> > > >      SessionKey session) {
>> > > >
>> > > >    requireNonNull(session);
>> > > >
>> > > >    try {
>> > > >
>> > > >      sessionValidator.checkAuthenticated(
>> > > >
>> > > >          session,
>> > > >
>> > > >          ImmutableSet.of(mutableJob.getKey().getRole()));
>> > > >
>> > > >    } catch (AuthFailedException e) {
>> > > >
>> > > >      return errorResponse(AUTH_FAILED, e);
>> > > >
>> > > >    }
>> > > >
>> > > >    // Request is authenticated and authorized, continue.
>> > > >
>> > > >  }
>> > > >
>> > > > becomes
>> > > >
>> > > >  @Override
>> > > >
>> > > >  public Response createJob(
>> > > >
>> > > >      JobConfiguration mutableJob,
>> > > >
>> > > >      @Nullable final Lock mutableLock) {
>> > > >
>> > > >    // subject is injected in the constructor by Guice each request.
>> > > >
>> > > >    // checkPermission will throw an unchecked
>> > > >
>> > > >    // AuthorizationException that bubbles up as a 401.
>> > > >
>> > > >    // This line could also be inserted by inspection of the method
>> > > >
>> > > >    // call in a security AOP layer.
>> > > >
>> > > >    subject.checkPermission(
>> > > >
>> > > >      // A Shiro WildcardPermission job:create:mesos:prod:labrat
>> > > >
>> > > >      new JobScopedPermission("job:create", mutableJob.getKey()));
>> > > >
>> > > >    // Request is authenticated and authorized, continue.
>> > > >
>> > > >  }
>> > > >
>> > > > Some admin methods are protected by annotations like
>> > > >
>> > > > @Requires(Capability.PROVISIONER)
>> > > >
>> > > > public Response startMaintenance(Set<String> hosts, SessionKey
>> session)
>> > > { …
>> > > > }
>> > > >
>> > > > They'd become
>> > > >
>> > > > @RequiresPermission("maintenance:create")
>> > > >
>> > > > public Response startMaintenance(Set<String> hosts) { … }
>> > > > Client-side changes
>> > > >
>> > > > No changes are necessary to use HTTP Basic Auth - requests will
>> > > > automatically use a .netrc file today.
>> > > >
>> > > > An optional dependency on kerberos and requests-kerberos can be added
>> > to
>> > > > support SPNEGO authentication.
>> > > > Timeline
>> > > >
>> > > > I would like to land support for HTTP Basic Auth and SPNEGO in 0.8.0
>> > and
>> > > > deprecate the SessionKey-based API for authentication in favor of
>> fully
>> > > > transport-based authentication.
>> > > >
>> > > > In 0.9.0 I propose removing SessionKey from the API entirely along
>> with
>> > > > SessionValidator from the scheduler.
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Zameer Manji
>> > >
>> >
>>

Mime
View raw message