post processing for integrated security

[Jinmei Liao <ji...@pivotal.io>]

While working on the integrated security for gemfire9/geode1, we are
frequently baffled by this post-processing functionality that's been lumped
into security. Here are a few observations we've come up with and want to
run with the dev community for comments:

1. Post processing is not authorization. At this point, all necessary
authorization should already be done and satisfied.

2. Post processing is related to security in the sense that it needs a
Principal in the context, but it's not part of the authorization.

3. Previous implementation (client-server) adds post process after every
authorization checks. We want to make a clean separation of these two
concepts. New interfaces of post processing will be introduced (so that we
can preserve the old behavior if user is implementing the old interface),
and will ONLY be added to the "get" and "query" data operations.

4. The new interface will look like below:
public Object processValue(Principal principal, String regionPath, Object
key, Object value)

Is this a sufficient interface to begin with? Do you have any client that
would need post processor to do something completely different?

Thank you for all your feedback.

-- 
Cheers

Jinmei

Re: post processing for integrated security

[Jinmei Liao <ji...@pivotal.io>]

Oh, yes. In the new model we are working on, users can just configure the
security with no custom implementation. But if they want to do something
crazy, they can still grab these interfaces and implement their own way.

On Fri, Jun 17, 2016 at 1:57 PM, Michael Stolz <ms...@pivotal.io> wrote:

> But the new model is supposed to be configuration only no user code, so I
> don't think it applies
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
> On Jun 17, 2016 4:48 PM, "Jinmei Liao" <ji...@pivotal.io> wrote:
>
> > If we are only doing post-processing for get and query, then it's not too
> > much work adding it into the new model.
> >
> > On Fri, Jun 17, 2016 at 12:00 PM, Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > Post processing is there to filter the data returned by a get or a
> query.
> > > But it requires that they write code, so it is probably only pertinent
> > for
> > > the old security model not for the new fully configurable End-to-end
> > model
> > > that we have begun discussing.
> > >
> > > So MAYBE we're actually doing too much work in keeping it for the new
> > > model.
> > >
> > > Thoughts?
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: 631-835-4771
> > >
> > > On Fri, Jun 17, 2016 at 11:44 AM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > > > While working on the integrated security for gemfire9/geode1, we are
> > > > frequently baffled by this post-processing functionality that's been
> > > lumped
> > > > into security. Here are a few observations we've come up with and
> want
> > to
> > > > run with the dev community for comments:
> > > >
> > > > 1. Post processing is not authorization. At this point, all necessary
> > > > authorization should already be done and satisfied.
> > > >
> > > > 2. Post processing is related to security in the sense that it needs
> a
> > > > Principal in the context, but it's not part of the authorization.
> > > >
> > > > 3. Previous implementation (client-server) adds post process after
> > every
> > > > authorization checks. We want to make a clean separation of these two
> > > > concepts. New interfaces of post processing will be introduced (so
> that
> > > we
> > > > can preserve the old behavior if user is implementing the old
> > interface),
> > > > and will ONLY be added to the "get" and "query" data operations.
> > > >
> > > > 4. The new interface will look like below:
> > > > public Object processValue(Principal principal, String regionPath,
> > Object
> > > > key, Object value)
> > > >
> > > > Is this a sufficient interface to begin with? Do you have any client
> > that
> > > > would need post processor to do something completely different?
> > > >
> > > > Thank you for all your feedback.
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: post processing for integrated security

[Michael Stolz <ms...@pivotal.io>]

But the new model is supposed to be configuration only no user code, so I
don't think it applies

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Jun 17, 2016 4:48 PM, "Jinmei Liao" <ji...@pivotal.io> wrote:

> If we are only doing post-processing for get and query, then it's not too
> much work adding it into the new model.
>
> On Fri, Jun 17, 2016 at 12:00 PM, Michael Stolz <ms...@pivotal.io> wrote:
>
> > Post processing is there to filter the data returned by a get or a query.
> > But it requires that they write code, so it is probably only pertinent
> for
> > the old security model not for the new fully configurable End-to-end
> model
> > that we have begun discussing.
> >
> > So MAYBE we're actually doing too much work in keeping it for the new
> > model.
> >
> > Thoughts?
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
> >
> > On Fri, Jun 17, 2016 at 11:44 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > While working on the integrated security for gemfire9/geode1, we are
> > > frequently baffled by this post-processing functionality that's been
> > lumped
> > > into security. Here are a few observations we've come up with and want
> to
> > > run with the dev community for comments:
> > >
> > > 1. Post processing is not authorization. At this point, all necessary
> > > authorization should already be done and satisfied.
> > >
> > > 2. Post processing is related to security in the sense that it needs a
> > > Principal in the context, but it's not part of the authorization.
> > >
> > > 3. Previous implementation (client-server) adds post process after
> every
> > > authorization checks. We want to make a clean separation of these two
> > > concepts. New interfaces of post processing will be introduced (so that
> > we
> > > can preserve the old behavior if user is implementing the old
> interface),
> > > and will ONLY be added to the "get" and "query" data operations.
> > >
> > > 4. The new interface will look like below:
> > > public Object processValue(Principal principal, String regionPath,
> Object
> > > key, Object value)
> > >
> > > Is this a sufficient interface to begin with? Do you have any client
> that
> > > would need post processor to do something completely different?
> > >
> > > Thank you for all your feedback.
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: post processing for integrated security

[Jinmei Liao <ji...@pivotal.io>]

If we are only doing post-processing for get and query, then it's not too
much work adding it into the new model.

On Fri, Jun 17, 2016 at 12:00 PM, Michael Stolz <ms...@pivotal.io> wrote:

> Post processing is there to filter the data returned by a get or a query.
> But it requires that they write code, so it is probably only pertinent for
> the old security model not for the new fully configurable End-to-end model
> that we have begun discussing.
>
> So MAYBE we're actually doing too much work in keeping it for the new
> model.
>
> Thoughts?
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Fri, Jun 17, 2016 at 11:44 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > While working on the integrated security for gemfire9/geode1, we are
> > frequently baffled by this post-processing functionality that's been
> lumped
> > into security. Here are a few observations we've come up with and want to
> > run with the dev community for comments:
> >
> > 1. Post processing is not authorization. At this point, all necessary
> > authorization should already be done and satisfied.
> >
> > 2. Post processing is related to security in the sense that it needs a
> > Principal in the context, but it's not part of the authorization.
> >
> > 3. Previous implementation (client-server) adds post process after every
> > authorization checks. We want to make a clean separation of these two
> > concepts. New interfaces of post processing will be introduced (so that
> we
> > can preserve the old behavior if user is implementing the old interface),
> > and will ONLY be added to the "get" and "query" data operations.
> >
> > 4. The new interface will look like below:
> > public Object processValue(Principal principal, String regionPath, Object
> > key, Object value)
> >
> > Is this a sufficient interface to begin with? Do you have any client that
> > would need post processor to do something completely different?
> >
> > Thank you for all your feedback.
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: post processing for integrated security

[Michael Stolz <ms...@pivotal.io>]

Post processing is there to filter the data returned by a get or a query.
But it requires that they write code, so it is probably only pertinent for
the old security model not for the new fully configurable End-to-end model
that we have begun discussing.

So MAYBE we're actually doing too much work in keeping it for the new model.

Thoughts?


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Jun 17, 2016 at 11:44 AM, Jinmei Liao <ji...@pivotal.io> wrote:

> While working on the integrated security for gemfire9/geode1, we are
> frequently baffled by this post-processing functionality that's been lumped
> into security. Here are a few observations we've come up with and want to
> run with the dev community for comments:
>
> 1. Post processing is not authorization. At this point, all necessary
> authorization should already be done and satisfied.
>
> 2. Post processing is related to security in the sense that it needs a
> Principal in the context, but it's not part of the authorization.
>
> 3. Previous implementation (client-server) adds post process after every
> authorization checks. We want to make a clean separation of these two
> concepts. New interfaces of post processing will be introduced (so that we
> can preserve the old behavior if user is implementing the old interface),
> and will ONLY be added to the "get" and "query" data operations.
>
> 4. The new interface will look like below:
> public Object processValue(Principal principal, String regionPath, Object
> key, Object value)
>
> Is this a sufficient interface to begin with? Do you have any client that
> would need post processor to do something completely different?
>
> Thank you for all your feedback.
>
> --
> Cheers
>
> Jinmei
>