aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: [DISCUSS] Use the Apache Shiro framework for scheduler security
Date Wed, 11 Feb 2015 23:19:14 GMT
+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 <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