aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <kevi...@apache.org>
Subject Re: [DISCUSS] Use the Apache Shiro framework for scheduler security
Date Wed, 11 Feb 2015 23:23:18 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message