aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <>
Subject [DISCUSS] Use the Apache Shiro framework for scheduler security
Date Wed, 11 Feb 2015 23:13:58 GMT
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
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
framework. No public implementations exist.

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.

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

2. Ability to integrate Aurora with my enterprise SSO (Kerberos+LDAP for
example) by implementing a custom Shiro Realm

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

4. Ability to authenticate to the scheduler API using Kerberos (via SPNEGO
<>) or HTTP Basic auth.

5. Ability to perform authenticated write operations on a job via the web UI
Suggested Reading

Shiro has excellent documentation and is a fellow Apache Foundation
project. I suggest you check out at least the 10-minute tutorial
<> and the Guice integration
documentation <>.
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


 public Response createJob(

     JobConfiguration mutableJob,

     @Nullable final Lock mutableLock,

     SessionKey session) {


   try {




   } catch (AuthFailedException e) {

     return errorResponse(AUTH_FAILED, e);


   // Request is authenticated and authorized, continue.




 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.


     // 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


public Response startMaintenance(Set<String> hosts, SessionKey session) { …

They'd become


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.

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.

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