Hi Jun,

We will be using the AccessControlContext corresponding to the current
calling context (i.e. on the current thread). So concurrent Subject.doAs()
in other threads will not have any impact. On the current thread, we are
using the Subject corresponding to the latest Subject.doAs(). This is safe
since callbacks are triggered by SaslClient only in code invoked within a
Subject.doAs() block in Kafka. For example (from
SaslClientAuthenticator.java):

        return Subject.doAs(subject, new PrivilegedExceptionAction<byte[]>()
{

            public byte[] run() throws SaslException {

                return saslClient.evaluateChallenge(saslToken);

            }

        }


Kerberos implementation in the JRE already relies on Subject from the
current calling context. So Kafka code does have to guarantee that these
operations are performed under a Subject.doAs() anyway.



On Wed, Oct 26, 2016 at 9:26 PM, Jun Rao <j...@confluent.io> wrote:

> Hi, Rajini,
>
> The javadoc of Subject.getSubjectAccessControlContext
> <https://docs.oracle.com/javase/7/docs/api/java/
> security/AccessControlContext.html>
> acc)
> says the following. So, are we depending on the correct ordering to get the
> right subject? Is there any issue if two Subject.doAs() are called
> concurrently?
>
> "The AccessControlContext may contain many Subjects (from nested doAs
> calls).
> In this situation, the most recent Subject associated with the
> AccessControlContext is returned"
>
> Thanks,
>
> Jun
>
> On Wed, Oct 26, 2016 at 5:25 AM, Rajini Sivaram <
> rajinisiva...@googlemail.com> wrote:
>
> > Hi Jun,
> >
> > The main processing method in the callback handler is "handle(Callback[]
> > callbacks)". This method is invoked by SaslClient either when the
> > SaslClient
> > is constructed or when Kafka's SASL authentication code invokes
> > saslClient.evaluateChallenge(). These are always done under
> > Subject.doAs() -
> > this is already the case in Kafka. Hence handle() method of the shared
> > callback handler can get Subject from the calling context and this
> Subject
> > corresponds to the client connection for which callback is being
> requested.
> >
> > *Current per-connection SaslClientCallbackHandler:*
> >
> >
> >     private Subject subject;
> >
> >     @Override
> >
> >     public void configure(Map<String, ?> configs, Mode mode, Subject
> > subject, String mechanism) {
> >
> >         this.isKerberos = mechanism.equals(SaslConfigs.
> GSSAPI_MECHANISM);
> >
> >         this.subject = subject;
> >
> >     }
> >
> >     @Override
> >
> >     public void handle(Callback[] callbacks) throws
> > UnsupportedCallbackException {
> >
> >         // Uses this.subject
> >
> >         ....
> >
> >     }
> >
> >
> > *Proposed shared **SaslClientCallbackHandler**:*
> >
> >     @Override
> >
> >     public void configure(Map<String, ?> configs, String saslMechanism) {
> >
> >     }
> >
> >     @Override
> >
> >     public void handle(Callback[] callbacks) throws
> > UnsupportedCallbackException {
> >
> >         Subject subject = Subject.getSubject(
> > AccessController.getContext());
> >
> >         ....
> >
> >     }
> >
> >
> >
> >
> > On Wed, Oct 26, 2016 at 2:58 AM, Jun Rao <j...@confluent.io> wrote:
> >
> > > Hi, Rajini,
> > >
> > > Thanks for the proposal.
> > >
> > > One quick question. The KIP says "SaslClientCallbackHandler will be
> > > modified to obtain Subject using
> > > *Subject.getSubject(AccessController.getContext())* to avoid the
> current
> > > per-connection state." Since subject is going to be different for
> > different
> > > connections, how do we get the connection specific subject if there is
> > only
> > > a single instance of the callback handler? The modification seems to
> call
> > > only some static methods.
> > >
> > > Jun
> > >
> > >
> > >
> > > On Tue, Oct 11, 2016 at 7:28 AM, Rajini Sivaram <
> > > rajinisiva...@googlemail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have just created KIP-86 make callback handlers in SASL
> configurable
> > so
> > > > that credential providers for SASL/PLAIN (and SASL/SCRAM when it is
> > > > implemented) can be used with custom credential callbacks:
> > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > 86%3A+Configurable+SASL+callback+handlers
> > > >
> > > > Comments and suggestions are welcome.
> > > >
> > > > Thank you...
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>



-- 
Regards,

Rajini

Reply via email to