You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by James Duong <ja...@bitquilltech.com> on 2020/08/19 19:46:11 UTC
Authentication Redeisgn
Hi Arrow-Dev,
I've written up a proposal to make some enhancements to the authentication
process. I've captured the overall goals on JIRA here:
https://issues.apache.org/jira/browse/ARROW-9804
The proposal itself is in this Google Doc:
https://docs.google.com/document/d/1TutHf9ttw3rLzBvYxJXP2q6fZHYmROu-gyKfniOntQY/edit#
The goals are primarily to decouple authentication from the handshake
process and integrate more easily with HTTP authentication mechanisms such
as OAuth 2.0.
There are suggestions to add some simple session-related communication
(session properties, server capabilities) as part of the proposal.
I've written a POC of the proposed changes here for authentication only
(not the handshake):
https://github.com/apache/arrow/pull/7994
Thanks!
--
*James Duong*
Lead Software Developer
Bit Quill Technologies Inc.
Direct: +1.604.562.6082 | jamesd@bitquilltech.com
https://www.bitquilltech.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure, or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message. Thank you.
Re: [Flight Format] Authentication Redesign
Posted by David Li <li...@gmail.com>.
Hey James,
I think adding a separate capabilities endpoint is a good idea - it
doesn't need to be a bidirectional streaming endpoint which would
simplify implementation/usage and it would make it easier to maintain
backwards compatibility or slowly phase out handshake.
Best,
David
On 9/4/20, James Duong <ja...@bitquilltech.com> wrote:
> Are we concerned about backward compatibility with older FlightClients?
> Would it make sense to continue to support handshakes with auth payloads
> in addition to header-based authentication using middlewares? Perhaps we
> create a dedicated endpoint for server capabilities if we need to remain
> backward compatible.
>
> On Thu, Sep 3, 2020 at 6:38 AM David Li <li...@gmail.com> wrote:
>
>> The C++/Python authentication implementation is entirely different
>> (because the C++/Python/Java gRPC APIs are in turn entirely
>> different). In particular, gRPC middleware in C++ is still
>> experimental (compared to Java) and much more limited (unless recent
>> versions changed this). C++/Python might function better as a set of
>> middleware implementations in the client which can attach/read headers
>> as necessary.
>>
>> David
>>
>> On 9/2/20, James Duong <ja...@bitquilltech.com> wrote:
>> > Looking towards the future a bit, I don't see some of the facilities we
>> > used for the Java code in the C++ Flight port.
>> > Primarily the use of CallOptions -- I don't see existing functionality
>> for
>> > wrapping the gRPC stub within the context of
>> > a single request. I do see that we pass in FlightCallOptions with each
>> RPC
>> > call on the client, but the FlightCallOptions
>> > class doesn't appear to be extensible, and neither do the
>> > IpcReadOptions
>> > and IpcWriteOptions within
>> > the FlightCallOptions.
>> >
>> > On Tue, Sep 1, 2020 at 6:15 PM David Li <li...@gmail.com> wrote:
>> >
>> >> Hey James,
>> >>
>> >> I won't be able to attend tomorrow, but seeing as I've been commenting
>> >> so far - the changes as summarized in the presentation (+I think the
>> >> latest comments in the doc) look good to me, thanks for working
>> >> through the proposal with us.
>> >>
>> >> Best,
>> >> David
>> >>
>> >> On 9/1/20, James Duong <ja...@bitquilltech.com> wrote:
>> >> > Hi,
>> >> >
>> >> > I would like to talk about the changes in the design document and PR
>> in
>> >> > tomorrow's meeting.
>> >> >
>> >> > I've created a slide deck to get the discussion going.
>> >> >
>> >> >
>> >>
>> https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
>> >> >
>> >> > Thanks!
>> >> >
>> >> > On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com>
>> >> > wrote:
>> >> >
>> >> >> Hi everyone,
>> >> >> I've updated the PR and responded to comments in the proposal
>> >> >> document.
>> >> >>
>> >> >> The PR now makes handshake optional and sends auth information with
>> >> every
>> >> >> request.
>> >> >> The client now needs to supply a CredentialCallOption containing
>> >> >> auth
>> >> >> information (as a Consumer<headers>), which
>> >> >> we'll convert to a gRPC CallCredentials under the hood, and use
>> >> >> that
>> >> >> to
>> >> >> write headers.
>> >> >>
>> >> >> On Thu, Aug 20, 2020 at 2:14 PM James Duong
>> >> >> <jamesd@bitquilltech.com
>> >
>> >> >> wrote:
>> >> >>
>> >> >>> Comments should be enabled now.
>> >> >>>
>> >> >>> Thanks for the feedback so far.
>> >> >>>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> *James Duong*
>> >> >> Lead Software Developer
>> >> >> Bit Quill Technologies Inc.
>> >> >> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
>> >> >> https://www.bitquilltech.com
>> >> >>
>> >> >> This email message is for the sole use of the intended recipient(s)
>> >> >> and
>> >> >> may contain confidential and privileged information. Any
>> unauthorized
>> >> >> review, use, disclosure, or distribution is prohibited. If you are
>> >> >> not
>> >> >> the
>> >> >> intended recipient, please contact the sender by reply email and
>> >> >> destroy
>> >> >> all copies of the original message. Thank you.
>> >> >>
>> >> >
>> >>
>> >
>> >
>> > --
>> >
>> > *James Duong*
>> > Lead Software Developer
>> > Bit Quill Technologies Inc.
>> > Direct: +1.604.562.6082 | jamesd@bitquilltech.com
>> > https://www.bitquilltech.com
>> >
>> > This email message is for the sole use of the intended recipient(s) and
>> may
>> > contain confidential and privileged information. Any unauthorized
>> review,
>> > use, disclosure, or distribution is prohibited. If you are not the
>> > intended recipient, please contact the sender by reply email and
>> > destroy
>> > all copies of the original message. Thank you.
>> >
>>
>
>
> --
>
> *James Duong*
> Lead Software Developer
> Bit Quill Technologies Inc.
> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> https://www.bitquilltech.com
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure, or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
>
Re: [Flight Format] Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Are we concerned about backward compatibility with older FlightClients?
Would it make sense to continue to support handshakes with auth payloads
in addition to header-based authentication using middlewares? Perhaps we
create a dedicated endpoint for server capabilities if we need to remain
backward compatible.
On Thu, Sep 3, 2020 at 6:38 AM David Li <li...@gmail.com> wrote:
> The C++/Python authentication implementation is entirely different
> (because the C++/Python/Java gRPC APIs are in turn entirely
> different). In particular, gRPC middleware in C++ is still
> experimental (compared to Java) and much more limited (unless recent
> versions changed this). C++/Python might function better as a set of
> middleware implementations in the client which can attach/read headers
> as necessary.
>
> David
>
> On 9/2/20, James Duong <ja...@bitquilltech.com> wrote:
> > Looking towards the future a bit, I don't see some of the facilities we
> > used for the Java code in the C++ Flight port.
> > Primarily the use of CallOptions -- I don't see existing functionality
> for
> > wrapping the gRPC stub within the context of
> > a single request. I do see that we pass in FlightCallOptions with each
> RPC
> > call on the client, but the FlightCallOptions
> > class doesn't appear to be extensible, and neither do the IpcReadOptions
> > and IpcWriteOptions within
> > the FlightCallOptions.
> >
> > On Tue, Sep 1, 2020 at 6:15 PM David Li <li...@gmail.com> wrote:
> >
> >> Hey James,
> >>
> >> I won't be able to attend tomorrow, but seeing as I've been commenting
> >> so far - the changes as summarized in the presentation (+I think the
> >> latest comments in the doc) look good to me, thanks for working
> >> through the proposal with us.
> >>
> >> Best,
> >> David
> >>
> >> On 9/1/20, James Duong <ja...@bitquilltech.com> wrote:
> >> > Hi,
> >> >
> >> > I would like to talk about the changes in the design document and PR
> in
> >> > tomorrow's meeting.
> >> >
> >> > I've created a slide deck to get the discussion going.
> >> >
> >> >
> >>
> https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
> >> >
> >> > Thanks!
> >> >
> >> > On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com>
> >> > wrote:
> >> >
> >> >> Hi everyone,
> >> >> I've updated the PR and responded to comments in the proposal
> >> >> document.
> >> >>
> >> >> The PR now makes handshake optional and sends auth information with
> >> every
> >> >> request.
> >> >> The client now needs to supply a CredentialCallOption containing auth
> >> >> information (as a Consumer<headers>), which
> >> >> we'll convert to a gRPC CallCredentials under the hood, and use that
> >> >> to
> >> >> write headers.
> >> >>
> >> >> On Thu, Aug 20, 2020 at 2:14 PM James Duong <jamesd@bitquilltech.com
> >
> >> >> wrote:
> >> >>
> >> >>> Comments should be enabled now.
> >> >>>
> >> >>> Thanks for the feedback so far.
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> *James Duong*
> >> >> Lead Software Developer
> >> >> Bit Quill Technologies Inc.
> >> >> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> >> >> https://www.bitquilltech.com
> >> >>
> >> >> This email message is for the sole use of the intended recipient(s)
> >> >> and
> >> >> may contain confidential and privileged information. Any
> unauthorized
> >> >> review, use, disclosure, or distribution is prohibited. If you are
> >> >> not
> >> >> the
> >> >> intended recipient, please contact the sender by reply email and
> >> >> destroy
> >> >> all copies of the original message. Thank you.
> >> >>
> >> >
> >>
> >
> >
> > --
> >
> > *James Duong*
> > Lead Software Developer
> > Bit Quill Technologies Inc.
> > Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> > https://www.bitquilltech.com
> >
> > This email message is for the sole use of the intended recipient(s) and
> may
> > contain confidential and privileged information. Any unauthorized
> review,
> > use, disclosure, or distribution is prohibited. If you are not the
> > intended recipient, please contact the sender by reply email and destroy
> > all copies of the original message. Thank you.
> >
>
--
*James Duong*
Lead Software Developer
Bit Quill Technologies Inc.
Direct: +1.604.562.6082 | jamesd@bitquilltech.com
https://www.bitquilltech.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure, or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message. Thank you.
Re: [Flight Format] Authentication Redesign
Posted by David Li <li...@gmail.com>.
The C++/Python authentication implementation is entirely different
(because the C++/Python/Java gRPC APIs are in turn entirely
different). In particular, gRPC middleware in C++ is still
experimental (compared to Java) and much more limited (unless recent
versions changed this). C++/Python might function better as a set of
middleware implementations in the client which can attach/read headers
as necessary.
David
On 9/2/20, James Duong <ja...@bitquilltech.com> wrote:
> Looking towards the future a bit, I don't see some of the facilities we
> used for the Java code in the C++ Flight port.
> Primarily the use of CallOptions -- I don't see existing functionality for
> wrapping the gRPC stub within the context of
> a single request. I do see that we pass in FlightCallOptions with each RPC
> call on the client, but the FlightCallOptions
> class doesn't appear to be extensible, and neither do the IpcReadOptions
> and IpcWriteOptions within
> the FlightCallOptions.
>
> On Tue, Sep 1, 2020 at 6:15 PM David Li <li...@gmail.com> wrote:
>
>> Hey James,
>>
>> I won't be able to attend tomorrow, but seeing as I've been commenting
>> so far - the changes as summarized in the presentation (+I think the
>> latest comments in the doc) look good to me, thanks for working
>> through the proposal with us.
>>
>> Best,
>> David
>>
>> On 9/1/20, James Duong <ja...@bitquilltech.com> wrote:
>> > Hi,
>> >
>> > I would like to talk about the changes in the design document and PR in
>> > tomorrow's meeting.
>> >
>> > I've created a slide deck to get the discussion going.
>> >
>> >
>> https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
>> >
>> > Thanks!
>> >
>> > On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com>
>> > wrote:
>> >
>> >> Hi everyone,
>> >> I've updated the PR and responded to comments in the proposal
>> >> document.
>> >>
>> >> The PR now makes handshake optional and sends auth information with
>> every
>> >> request.
>> >> The client now needs to supply a CredentialCallOption containing auth
>> >> information (as a Consumer<headers>), which
>> >> we'll convert to a gRPC CallCredentials under the hood, and use that
>> >> to
>> >> write headers.
>> >>
>> >> On Thu, Aug 20, 2020 at 2:14 PM James Duong <ja...@bitquilltech.com>
>> >> wrote:
>> >>
>> >>> Comments should be enabled now.
>> >>>
>> >>> Thanks for the feedback so far.
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *James Duong*
>> >> Lead Software Developer
>> >> Bit Quill Technologies Inc.
>> >> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
>> >> https://www.bitquilltech.com
>> >>
>> >> This email message is for the sole use of the intended recipient(s)
>> >> and
>> >> may contain confidential and privileged information. Any unauthorized
>> >> review, use, disclosure, or distribution is prohibited. If you are
>> >> not
>> >> the
>> >> intended recipient, please contact the sender by reply email and
>> >> destroy
>> >> all copies of the original message. Thank you.
>> >>
>> >
>>
>
>
> --
>
> *James Duong*
> Lead Software Developer
> Bit Quill Technologies Inc.
> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> https://www.bitquilltech.com
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure, or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
>
Re: [Flight Format] Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Looking towards the future a bit, I don't see some of the facilities we
used for the Java code in the C++ Flight port.
Primarily the use of CallOptions -- I don't see existing functionality for
wrapping the gRPC stub within the context of
a single request. I do see that we pass in FlightCallOptions with each RPC
call on the client, but the FlightCallOptions
class doesn't appear to be extensible, and neither do the IpcReadOptions
and IpcWriteOptions within
the FlightCallOptions.
On Tue, Sep 1, 2020 at 6:15 PM David Li <li...@gmail.com> wrote:
> Hey James,
>
> I won't be able to attend tomorrow, but seeing as I've been commenting
> so far - the changes as summarized in the presentation (+I think the
> latest comments in the doc) look good to me, thanks for working
> through the proposal with us.
>
> Best,
> David
>
> On 9/1/20, James Duong <ja...@bitquilltech.com> wrote:
> > Hi,
> >
> > I would like to talk about the changes in the design document and PR in
> > tomorrow's meeting.
> >
> > I've created a slide deck to get the discussion going.
> >
> >
> https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
> >
> > Thanks!
> >
> > On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com> wrote:
> >
> >> Hi everyone,
> >> I've updated the PR and responded to comments in the proposal document.
> >>
> >> The PR now makes handshake optional and sends auth information with
> every
> >> request.
> >> The client now needs to supply a CredentialCallOption containing auth
> >> information (as a Consumer<headers>), which
> >> we'll convert to a gRPC CallCredentials under the hood, and use that to
> >> write headers.
> >>
> >> On Thu, Aug 20, 2020 at 2:14 PM James Duong <ja...@bitquilltech.com>
> >> wrote:
> >>
> >>> Comments should be enabled now.
> >>>
> >>> Thanks for the feedback so far.
> >>>
> >>
> >>
> >> --
> >>
> >> *James Duong*
> >> Lead Software Developer
> >> Bit Quill Technologies Inc.
> >> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> >> https://www.bitquilltech.com
> >>
> >> This email message is for the sole use of the intended recipient(s) and
> >> may contain confidential and privileged information. Any unauthorized
> >> review, use, disclosure, or distribution is prohibited. If you are not
> >> the
> >> intended recipient, please contact the sender by reply email and destroy
> >> all copies of the original message. Thank you.
> >>
> >
>
--
*James Duong*
Lead Software Developer
Bit Quill Technologies Inc.
Direct: +1.604.562.6082 | jamesd@bitquilltech.com
https://www.bitquilltech.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure, or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message. Thank you.
Re: [Flight Format] Authentication Redesign
Posted by David Li <li...@gmail.com>.
Hey James,
I won't be able to attend tomorrow, but seeing as I've been commenting
so far - the changes as summarized in the presentation (+I think the
latest comments in the doc) look good to me, thanks for working
through the proposal with us.
Best,
David
On 9/1/20, James Duong <ja...@bitquilltech.com> wrote:
> Hi,
>
> I would like to talk about the changes in the design document and PR in
> tomorrow's meeting.
>
> I've created a slide deck to get the discussion going.
>
> https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
>
> Thanks!
>
> On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com> wrote:
>
>> Hi everyone,
>> I've updated the PR and responded to comments in the proposal document.
>>
>> The PR now makes handshake optional and sends auth information with every
>> request.
>> The client now needs to supply a CredentialCallOption containing auth
>> information (as a Consumer<headers>), which
>> we'll convert to a gRPC CallCredentials under the hood, and use that to
>> write headers.
>>
>> On Thu, Aug 20, 2020 at 2:14 PM James Duong <ja...@bitquilltech.com>
>> wrote:
>>
>>> Comments should be enabled now.
>>>
>>> Thanks for the feedback so far.
>>>
>>
>>
>> --
>>
>> *James Duong*
>> Lead Software Developer
>> Bit Quill Technologies Inc.
>> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
>> https://www.bitquilltech.com
>>
>> This email message is for the sole use of the intended recipient(s) and
>> may contain confidential and privileged information. Any unauthorized
>> review, use, disclosure, or distribution is prohibited. If you are not
>> the
>> intended recipient, please contact the sender by reply email and destroy
>> all copies of the original message. Thank you.
>>
>
Re: [Flight Format] Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Hi,
I would like to talk about the changes in the design document and PR in
tomorrow's meeting.
I've created a slide deck to get the discussion going.
https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
Thanks!
On Wed, Aug 26, 2020, 13:12 James Duong <ja...@bitquilltech.com> wrote:
> Hi everyone,
> I've updated the PR and responded to comments in the proposal document.
>
> The PR now makes handshake optional and sends auth information with every
> request.
> The client now needs to supply a CredentialCallOption containing auth
> information (as a Consumer<headers>), which
> we'll convert to a gRPC CallCredentials under the hood, and use that to
> write headers.
>
> On Thu, Aug 20, 2020 at 2:14 PM James Duong <ja...@bitquilltech.com>
> wrote:
>
>> Comments should be enabled now.
>>
>> Thanks for the feedback so far.
>>
>
>
> --
>
> *James Duong*
> Lead Software Developer
> Bit Quill Technologies Inc.
> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> https://www.bitquilltech.com
>
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential and privileged information. Any unauthorized
> review, use, disclosure, or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
>
Re: Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Hi everyone,
I've updated the PR and responded to comments in the proposal document.
The PR now makes handshake optional and sends auth information with every
request.
The client now needs to supply a CredentialCallOption containing auth
information (as a Consumer<headers>), which
we'll convert to a gRPC CallCredentials under the hood, and use that to
write headers.
On Thu, Aug 20, 2020 at 2:14 PM James Duong <ja...@bitquilltech.com> wrote:
> Comments should be enabled now.
>
> Thanks for the feedback so far.
>
--
*James Duong*
Lead Software Developer
Bit Quill Technologies Inc.
Direct: +1.604.562.6082 | jamesd@bitquilltech.com
https://www.bitquilltech.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure, or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message. Thank you.
Re: Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Comments should be enabled now.
Thanks for the feedback so far.
Re: Authentication Redesign
Posted by Antoine Pitrou <an...@python.org>.
Could you enable comments on this document?
Le 20/08/2020 à 18:49, James Duong a écrit :
> Thanks Ryan.
> I had an issue moving this document between a few other Google Drives.
>
> This is the correct link:
> https://docs.google.com/document/d/1k3hdbGeE89jiMZ2oKpoIZEs7HAQmVs_RWOmU7fTpLjQ/
>
>
>
> On Thu, Aug 20, 2020 at 12:48 AM Ryan Murray <ry...@dremio.com> wrote:
>
>> Hey James,
>>
>> Looks like the doc is not entirely readable. I am getting:
>>
>> '
>> File is in owner's trash
>> You will soon permanently lose access to this file. For continued access,
>> please make a copy.
>> '
>>
>> When I access it.
>>
>> Best,
>>
>> Ryan Murray | OSS Engineer
>>
>> +447540852009 | rymurr@dremio.com
>>
>>
>>
>> On Wed, Aug 19, 2020 at 9:43 PM James Duong <ja...@bitquilltech.com>
>> wrote:
>>
>>> Hi Arrow-Dev,
>>>
>>> I've written up a proposal to make some enhancements to the
>> authentication
>>> process. I've captured the overall goals on JIRA here:
>>> https://issues.apache.org/jira/browse/ARROW-9804
>>>
>>> The proposal itself is in this Google Doc:
>>>
>>>
>> https://docs.google.com/document/d/1TutHf9ttw3rLzBvYxJXP2q6fZHYmROu-gyKfniOntQY/edit#
>>>
>>> The goals are primarily to decouple authentication from the handshake
>>> process and integrate more easily with HTTP authentication mechanisms
>> such
>>> as OAuth 2.0.
>>>
>>> There are suggestions to add some simple session-related communication
>>> (session properties, server capabilities) as part of the proposal.
>>>
>>> I've written a POC of the proposed changes here for authentication only
>>> (not the handshake):
>>> https://github.com/apache/arrow/pull/7994
>>>
>>> Thanks!
>>>
>>> --
>>>
>>> *James Duong*
>>> Lead Software Developer
>>> Bit Quill Technologies Inc.
>>> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
>>> https://www.bitquilltech.com
>>>
>>> This email message is for the sole use of the intended recipient(s) and
>> may
>>> contain confidential and privileged information. Any unauthorized
>> review,
>>> use, disclosure, or distribution is prohibited. If you are not the
>>> intended recipient, please contact the sender by reply email and destroy
>>> all copies of the original message. Thank you.
>>>
>>
>
>
Re: Authentication Redesign
Posted by James Duong <ja...@bitquilltech.com>.
Thanks Ryan.
I had an issue moving this document between a few other Google Drives.
This is the correct link:
https://docs.google.com/document/d/1k3hdbGeE89jiMZ2oKpoIZEs7HAQmVs_RWOmU7fTpLjQ/
On Thu, Aug 20, 2020 at 12:48 AM Ryan Murray <ry...@dremio.com> wrote:
> Hey James,
>
> Looks like the doc is not entirely readable. I am getting:
>
> '
> File is in owner's trash
> You will soon permanently lose access to this file. For continued access,
> please make a copy.
> '
>
> When I access it.
>
> Best,
>
> Ryan Murray | OSS Engineer
>
> +447540852009 | rymurr@dremio.com
>
>
>
> On Wed, Aug 19, 2020 at 9:43 PM James Duong <ja...@bitquilltech.com>
> wrote:
>
> > Hi Arrow-Dev,
> >
> > I've written up a proposal to make some enhancements to the
> authentication
> > process. I've captured the overall goals on JIRA here:
> > https://issues.apache.org/jira/browse/ARROW-9804
> >
> > The proposal itself is in this Google Doc:
> >
> >
> https://docs.google.com/document/d/1TutHf9ttw3rLzBvYxJXP2q6fZHYmROu-gyKfniOntQY/edit#
> >
> > The goals are primarily to decouple authentication from the handshake
> > process and integrate more easily with HTTP authentication mechanisms
> such
> > as OAuth 2.0.
> >
> > There are suggestions to add some simple session-related communication
> > (session properties, server capabilities) as part of the proposal.
> >
> > I've written a POC of the proposed changes here for authentication only
> > (not the handshake):
> > https://github.com/apache/arrow/pull/7994
> >
> > Thanks!
> >
> > --
> >
> > *James Duong*
> > Lead Software Developer
> > Bit Quill Technologies Inc.
> > Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> > https://www.bitquilltech.com
> >
> > This email message is for the sole use of the intended recipient(s) and
> may
> > contain confidential and privileged information. Any unauthorized
> review,
> > use, disclosure, or distribution is prohibited. If you are not the
> > intended recipient, please contact the sender by reply email and destroy
> > all copies of the original message. Thank you.
> >
>
--
*James Duong*
Lead Software Developer
Bit Quill Technologies Inc.
Direct: +1.604.562.6082 | jamesd@bitquilltech.com
https://www.bitquilltech.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure, or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message. Thank you.
Re: Authentication Redeisgn
Posted by Ryan Murray <ry...@dremio.com>.
Hey James,
Looks like the doc is not entirely readable. I am getting:
'
File is in owner's trash
You will soon permanently lose access to this file. For continued access,
please make a copy.
'
When I access it.
Best,
Ryan Murray | OSS Engineer
+447540852009 | rymurr@dremio.com
On Wed, Aug 19, 2020 at 9:43 PM James Duong <ja...@bitquilltech.com> wrote:
> Hi Arrow-Dev,
>
> I've written up a proposal to make some enhancements to the authentication
> process. I've captured the overall goals on JIRA here:
> https://issues.apache.org/jira/browse/ARROW-9804
>
> The proposal itself is in this Google Doc:
>
> https://docs.google.com/document/d/1TutHf9ttw3rLzBvYxJXP2q6fZHYmROu-gyKfniOntQY/edit#
>
> The goals are primarily to decouple authentication from the handshake
> process and integrate more easily with HTTP authentication mechanisms such
> as OAuth 2.0.
>
> There are suggestions to add some simple session-related communication
> (session properties, server capabilities) as part of the proposal.
>
> I've written a POC of the proposed changes here for authentication only
> (not the handshake):
> https://github.com/apache/arrow/pull/7994
>
> Thanks!
>
> --
>
> *James Duong*
> Lead Software Developer
> Bit Quill Technologies Inc.
> Direct: +1.604.562.6082 | jamesd@bitquilltech.com
> https://www.bitquilltech.com
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure, or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
>