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.