Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAOTkfX5NxaD03DKE4S2D7P_AtwPjD6GYecgcG3EthouSbNMH4g@mail.gmail.com>
References: 
 <CAAATh-aa2f0Oxi4xqnW50QO7S9zvcHbNPjZ7t1oFw5oVVMEGWA@mail.gmail.com>
	<CAK7Zj11ZUPTxPaebBWkcVbCZcGM0HsmZHQw4TJvt51ZB-6_3Ug@mail.gmail.com>
	<CAAATh-aDE22OMvaMu0peMv8nKAY+=GW5X5pnA-yYyT1L0-e_aw@mail.gmail.com>
	<CAMnduq8Uvq0rQ8defwxjjt8sTnO=Svi_3S7ZguPMUYoAAZ59Dg@mail.gmail.com>
	<CAAATh-ad+9YZN=TuEH0pJk4Lm-0PXgsAw0qLuA6C7oB0i4VWXQ@mail.gmail.com>
	<CAOTkfX5NxaD03DKE4S2D7P_AtwPjD6GYecgcG3EthouSbNMH4g@mail.gmail.com>
Date: Wed, 11 Feb 2015 16:08:16 -0800
Message-ID: 
 <CAAATh-buT-UJaNuTNimFF-KBr2cxXfcEqzFWk8MOQgRV=YC++Q@mail.gmail.com>
Subject: Re: [DISCUSS] Use the Apache Shiro framework for scheduler security
From: Kevin Sweeney <kevints@apache.org>
To: Aurora <dev@aurora.incubator.apache.org>
Content-Type: multipart/alternative; boundary=001a11348266afd5c0050ed8ea13

--001a11348266afd5c0050ed8ea13
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that would be too big a patch to land all at once. I'd like to add
in Shiro permission checks and annotations incrementally behind this flag
as there are conceptually different changes that will benefit from small
reviews. If I take the approach of ripping out the current framework first
we could be left in an "old way's broken, new way's not finished yet" state=
.

On Wed, Feb 11, 2015 at 4:03 PM, Maxim Khutornenko <maxim@apache.org> wrote=
:

> 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, s=
o
> > 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 =3D=3D SHIRO before doing anything), but that means we'd=
 still
> >> have the legacy sessionValidator code in every RPC impl that would nee=
d
> to
> >> be wrapped in the inverse check (security_mode =3D=3D CAPABILITY_VALID=
ATOR).
> >>
> >> 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 t=
he
> >> > > SessionKey based API methods?
> >> > >
> >> > Yes for backwards-compatibility I think we'll need a flag to indicat=
e
> >> which
> >> > system to use. It will probably be an all-or-nothing setting (think
> >> > -security_mode=3DSHIRO|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/or=
g/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/or=
g/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 complet=
e:
> >> > > >
> >> > > > 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/perm=
ission/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 vi=
a
> 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 in=
to
> >> 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 meth=
od
> >> > > >
> >> > > >    // 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)
> >> > > { =E2=80=A6
> >> > > > }
> >> > > >
> >> > > > They'd become
> >> > > >
> >> > > > @RequiresPermission("maintenance:create")
> >> > > >
> >> > > > public Response startMaintenance(Set<String> hosts) { =E2=80=A6 =
}
> >> > > > 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 o=
f
> >> fully
> >> > > > transport-based authentication.
> >> > > >
> >> > > > In 0.9.0 I propose removing SessionKey from the API entirely alo=
ng
> >> with
> >> > > > SessionValidator from the scheduler.
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Zameer Manji
> >> > >
> >> >
> >>
>

--001a11348266afd5c0050ed8ea13--