You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Juan Cabrerizo <ju...@cloudsoft.io> on 2019/05/21 14:11:58 UTC
Allowing OAUTH in Apache Brooklyn Client (BR)
Hello all
I'm continuing with changes for allow oauth authentication in Apache
Brooklyn. I'm working now on the BR command line tool.
The initial idea is send the JWT access token in the headers instead send
the basic authentication header when the token is available after execute a
login command to get the token.
I'll modify the BR login command to allow inject headers and store it on
the yaml file and sent on the API calls. Is a new Authorization header is
available sent it rather than the default authentication.
Any concerns about this approach? I'm fully open to any idea.
Best regards.
Juan
--
Juan Cabrerizo
Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
E: juan@cloudsoft.io
L: https://www.linkedin.com/in/juancabrerizo/
Need a hand with AWS? Get a Free Consultation.
Re: Allowing OAUTH in Apache Brooklyn Client (BR)
Posted by Juan Cabrerizo <ju...@cloudsoft.io>.
Hi all
After adding some init test for getting the info from yaml file, i opened a
pull request.
I've been testing manually using different security providers:
oauth, AnyoneSecurityProvider and the default ExplicitUsersSecurityProvider
and it works as I expected.
here it is: https://github.com/apache/brooklyn-client/pull/77
Best regards.
Juan
On Thu, 23 May 2019 at 12:23, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
> Hi Alex,
> The current implementation returns `2` as exit code when the login fails
> or you try make a query and the authentication failed.
>
> Juan
>
>
> On Thu, 23 May 2019 at 12:09, Alex Heneveld <al...@cloudsoft.io> wrote:
>
>>
>> Juan-
>>
>> This looks really good to me.
>>
>> If you don't use OAuth, no change, and `br` works as it always has.
>>
>> If you do need OAuth, you define the process to get the header (maybe
>> another script, say br-my-oauth), which can then use`br` to persist the
>> header for subsequent usage by `br`. You'll have to explicitly
>> re-generate the header whenever the session times out.
>>
>> Alternatively the user could rename `br` to `br-original` then write
>> their own script `br` which tries `br-original` but if auth fails it
>> automaticalllly invokes `br-my-oauth` and retries `br-original`. That
>> way login would be as seamless as possible.
>>
>> Can we make it so `br` returns a special non-zero exit code on auth
>> faillure? (Different to exit code on other errors.)
>>
>> Best
>> Alex
>>
>>
>> On 23/05/2019 10:33, Juan Cabrerizo wrote:
>> > Hi Geoff. Thanks your your thoughts.
>> >
>> > As different oauth providers can implement login in very different ways,
>> > for the moment I'm bypassing the process for request the token. Once the
>> > user get it with an external mechanism, he can add it when do login
>> with br.
>> > As you said, once you use the token for login, you need sent it on all
>> REST
>> > calls for authentication.
>> > And also, I added a new parameter for do not request for user and
>> password.
>> > If it is added, br won't sent the current basic authentication header.
>> > The command will be executed as:
>> >
>> > br login http://server:port --noCredentials --header 'Authorization:
>> Bearer
>> > xxxxx.yyyyyy.zzzzz' --header 'OtherHeader=headerValue'
>> >
>> > This execution will crate this persisted yaml:
>> > {
>> > "credentials": {
>> > "http://localhost:8081": "Og=="
>> > },
>> > "credentialsRequired": false,
>> > "headers": {
>> > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
>> > "OtherHeader": "headerValue"
>> > },
>> > "skipSslChecks": false,
>> > "target": "http://localhost:8081"
>> > }
>> >
>> > If you don't add this new parameter, the behavior will be the same as
>> > before, so it won't affect that not use oauth.
>> > I defined for the moment `headers` and `credentialsRequired` as global
>> (no
>> > related to any target) as is for `skipSslChecks`
>> >
>> > Other more ambitious change could be modify the structure to something
>> like:
>> > {
>> > "servers": {
>> > "http://localhost:8081":{
>> >
>> > "credentials":"Odddg=="
>> >
>> > },
>> > http://remote1:8081":{
>> >
>> > "credentials":"xxxxx=="
>> >
>> > },
>> > http://remote2:8081":{
>> >
>> > "credentialsRequired": false,
>> >
>> > "headers": {
>> >
>> > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
>> >
>> > "OtherHeader": "headerValue"
>> >
>> > },
>> >
>> > },
>> >
>> > },
>> >
>> > "skipSslChecks": false,
>> > "target": "http://localhost:8081"
>> > }
>> >
>> > I already have the first version working and i'm testing it in a couple
>> of
>> > environments, probably I'c create a PR this week. I'm not sure if it
>> worth
>> > make more changes.
>> >
>> > Thanks again for your ideas.
>> >
>> > Regards
>> >
>> > Juan
>> >
>> > On Wed, 22 May 2019 at 23:12, Geoff Macartney <
>> geoff.macartney@gmail.com>
>> > wrote:
>> >
>> >> Hi Juan,
>> >>
>> >> If I understand you right you mean that the login command will do a
>> >> request to Brooklyn, sending the username and collected password, and
>> >> Brooklyn will do the interaction with the OAuth server to obtain a
>> token,
>> >> which it will return to the br tool (in the form of a JWT token). Then
>> br
>> >> can store that in its local .brooklyn_cli file. What is the REST
>> request
>> >> to be used for that login action?
>> >>
>> >> Subsequently all requests will be sent with
>> >>
>> >> Authorization: Bearer xxxxx.yyyyyy.zzzzz
>> >>
>> >> Where x.y.z is the JWT token.
>> >>
>> >> Is the above understanding right?
>> >>
>> >> How will your design support br being able to log in to some Brooklyn
>> >> servers without OAuth configured, and others that do use OAuth?
>> >>
>> >> Just a couple of thoughts, but I’m keen to see this. Happy to review
>> any
>> >> early draft pull requests you may have.
>> >>
>> >> Regards
>> >> Geoff
>> >>
>> >>> On 21 May 2019, at 15:11, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
>> >>>
>> >>> Hello all
>> >>>
>> >>> I'm continuing with changes for allow oauth authentication in Apache
>> >>> Brooklyn. I'm working now on the BR command line tool.
>> >>> The initial idea is send the JWT access token in the headers instead
>> send
>> >>> the basic authentication header when the token is available after
>> >> execute a
>> >>> login command to get the token.
>> >>>
>> >>> I'll modify the BR login command to allow inject headers and store it
>> on
>> >>> the yaml file and sent on the API calls. Is a new Authorization
>> header is
>> >>> available sent it rather than the default authentication.
>> >>>
>> >>> Any concerns about this approach? I'm fully open to any idea.
>> >>>
>> >>> Best regards.
>> >>>
>> >>> Juan
>> >>>
>> >>> --
>> >>> Juan Cabrerizo
>> >>> Software Engineer
>> >>>
>> >>> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
>> >>> E: juan@cloudsoft.io
>> >>> L: https://www.linkedin.com/in/juancabrerizo/
>> >>>
>> >>> Need a hand with AWS? Get a Free Consultation.
>> >>
>>
>>
>
> --
> Juan Cabrerizo
> Software Engineer
>
> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
> E: juan@cloudsoft.io
> L: https://www.linkedin.com/in/juancabrerizo/
>
> Need a hand with AWS? Get a Free Consultation.
>
--
Juan Cabrerizo
Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
E: juan@cloudsoft.io
L: https://www.linkedin.com/in/juancabrerizo/
Need a hand with AWS? Get a Free Consultation.
Re: Allowing OAUTH in Apache Brooklyn Client (BR)
Posted by Juan Cabrerizo <ju...@cloudsoft.io>.
Hi Alex,
The current implementation returns `2` as exit code when the login fails or
you try make a query and the authentication failed.
Juan
On Thu, 23 May 2019 at 12:09, Alex Heneveld <al...@cloudsoft.io> wrote:
>
> Juan-
>
> This looks really good to me.
>
> If you don't use OAuth, no change, and `br` works as it always has.
>
> If you do need OAuth, you define the process to get the header (maybe
> another script, say br-my-oauth), which can then use`br` to persist the
> header for subsequent usage by `br`. You'll have to explicitly
> re-generate the header whenever the session times out.
>
> Alternatively the user could rename `br` to `br-original` then write
> their own script `br` which tries `br-original` but if auth fails it
> automaticalllly invokes `br-my-oauth` and retries `br-original`. That
> way login would be as seamless as possible.
>
> Can we make it so `br` returns a special non-zero exit code on auth
> faillure? (Different to exit code on other errors.)
>
> Best
> Alex
>
>
> On 23/05/2019 10:33, Juan Cabrerizo wrote:
> > Hi Geoff. Thanks your your thoughts.
> >
> > As different oauth providers can implement login in very different ways,
> > for the moment I'm bypassing the process for request the token. Once the
> > user get it with an external mechanism, he can add it when do login with
> br.
> > As you said, once you use the token for login, you need sent it on all
> REST
> > calls for authentication.
> > And also, I added a new parameter for do not request for user and
> password.
> > If it is added, br won't sent the current basic authentication header.
> > The command will be executed as:
> >
> > br login http://server:port --noCredentials --header 'Authorization:
> Bearer
> > xxxxx.yyyyyy.zzzzz' --header 'OtherHeader=headerValue'
> >
> > This execution will crate this persisted yaml:
> > {
> > "credentials": {
> > "http://localhost:8081": "Og=="
> > },
> > "credentialsRequired": false,
> > "headers": {
> > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
> > "OtherHeader": "headerValue"
> > },
> > "skipSslChecks": false,
> > "target": "http://localhost:8081"
> > }
> >
> > If you don't add this new parameter, the behavior will be the same as
> > before, so it won't affect that not use oauth.
> > I defined for the moment `headers` and `credentialsRequired` as global
> (no
> > related to any target) as is for `skipSslChecks`
> >
> > Other more ambitious change could be modify the structure to something
> like:
> > {
> > "servers": {
> > "http://localhost:8081":{
> >
> > "credentials":"Odddg=="
> >
> > },
> > http://remote1:8081":{
> >
> > "credentials":"xxxxx=="
> >
> > },
> > http://remote2:8081":{
> >
> > "credentialsRequired": false,
> >
> > "headers": {
> >
> > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
> >
> > "OtherHeader": "headerValue"
> >
> > },
> >
> > },
> >
> > },
> >
> > "skipSslChecks": false,
> > "target": "http://localhost:8081"
> > }
> >
> > I already have the first version working and i'm testing it in a couple
> of
> > environments, probably I'c create a PR this week. I'm not sure if it
> worth
> > make more changes.
> >
> > Thanks again for your ideas.
> >
> > Regards
> >
> > Juan
> >
> > On Wed, 22 May 2019 at 23:12, Geoff Macartney <geoff.macartney@gmail.com
> >
> > wrote:
> >
> >> Hi Juan,
> >>
> >> If I understand you right you mean that the login command will do a
> >> request to Brooklyn, sending the username and collected password, and
> >> Brooklyn will do the interaction with the OAuth server to obtain a
> token,
> >> which it will return to the br tool (in the form of a JWT token). Then
> br
> >> can store that in its local .brooklyn_cli file. What is the REST
> request
> >> to be used for that login action?
> >>
> >> Subsequently all requests will be sent with
> >>
> >> Authorization: Bearer xxxxx.yyyyyy.zzzzz
> >>
> >> Where x.y.z is the JWT token.
> >>
> >> Is the above understanding right?
> >>
> >> How will your design support br being able to log in to some Brooklyn
> >> servers without OAuth configured, and others that do use OAuth?
> >>
> >> Just a couple of thoughts, but I’m keen to see this. Happy to review any
> >> early draft pull requests you may have.
> >>
> >> Regards
> >> Geoff
> >>
> >>> On 21 May 2019, at 15:11, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
> >>>
> >>> Hello all
> >>>
> >>> I'm continuing with changes for allow oauth authentication in Apache
> >>> Brooklyn. I'm working now on the BR command line tool.
> >>> The initial idea is send the JWT access token in the headers instead
> send
> >>> the basic authentication header when the token is available after
> >> execute a
> >>> login command to get the token.
> >>>
> >>> I'll modify the BR login command to allow inject headers and store it
> on
> >>> the yaml file and sent on the API calls. Is a new Authorization header
> is
> >>> available sent it rather than the default authentication.
> >>>
> >>> Any concerns about this approach? I'm fully open to any idea.
> >>>
> >>> Best regards.
> >>>
> >>> Juan
> >>>
> >>> --
> >>> Juan Cabrerizo
> >>> Software Engineer
> >>>
> >>> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
> >>> E: juan@cloudsoft.io
> >>> L: https://www.linkedin.com/in/juancabrerizo/
> >>>
> >>> Need a hand with AWS? Get a Free Consultation.
> >>
>
>
--
Juan Cabrerizo
Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
E: juan@cloudsoft.io
L: https://www.linkedin.com/in/juancabrerizo/
Need a hand with AWS? Get a Free Consultation.
Re: Allowing OAUTH in Apache Brooklyn Client (BR)
Posted by Alex Heneveld <al...@cloudsoft.io>.
Juan-
This looks really good to me.
If you don't use OAuth, no change, and `br` works as it always has.
If you do need OAuth, you define the process to get the header (maybe
another script, say br-my-oauth), which can then use`br` to persist the
header for subsequent usage by `br`. You'll have to explicitly
re-generate the header whenever the session times out.
Alternatively the user could rename `br` to `br-original` then write
their own script `br` which tries `br-original` but if auth fails it
automaticalllly invokes `br-my-oauth` and retries `br-original`. That
way login would be as seamless as possible.
Can we make it so `br` returns a special non-zero exit code on auth
faillure? (Different to exit code on other errors.)
Best
Alex
On 23/05/2019 10:33, Juan Cabrerizo wrote:
> Hi Geoff. Thanks your your thoughts.
>
> As different oauth providers can implement login in very different ways,
> for the moment I'm bypassing the process for request the token. Once the
> user get it with an external mechanism, he can add it when do login with br.
> As you said, once you use the token for login, you need sent it on all REST
> calls for authentication.
> And also, I added a new parameter for do not request for user and password.
> If it is added, br won't sent the current basic authentication header.
> The command will be executed as:
>
> br login http://server:port --noCredentials --header 'Authorization: Bearer
> xxxxx.yyyyyy.zzzzz' --header 'OtherHeader=headerValue'
>
> This execution will crate this persisted yaml:
> {
> "credentials": {
> "http://localhost:8081": "Og=="
> },
> "credentialsRequired": false,
> "headers": {
> "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
> "OtherHeader": "headerValue"
> },
> "skipSslChecks": false,
> "target": "http://localhost:8081"
> }
>
> If you don't add this new parameter, the behavior will be the same as
> before, so it won't affect that not use oauth.
> I defined for the moment `headers` and `credentialsRequired` as global (no
> related to any target) as is for `skipSslChecks`
>
> Other more ambitious change could be modify the structure to something like:
> {
> "servers": {
> "http://localhost:8081":{
>
> "credentials":"Odddg=="
>
> },
> http://remote1:8081":{
>
> "credentials":"xxxxx=="
>
> },
> http://remote2:8081":{
>
> "credentialsRequired": false,
>
> "headers": {
>
> "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
>
> "OtherHeader": "headerValue"
>
> },
>
> },
>
> },
>
> "skipSslChecks": false,
> "target": "http://localhost:8081"
> }
>
> I already have the first version working and i'm testing it in a couple of
> environments, probably I'c create a PR this week. I'm not sure if it worth
> make more changes.
>
> Thanks again for your ideas.
>
> Regards
>
> Juan
>
> On Wed, 22 May 2019 at 23:12, Geoff Macartney <ge...@gmail.com>
> wrote:
>
>> Hi Juan,
>>
>> If I understand you right you mean that the login command will do a
>> request to Brooklyn, sending the username and collected password, and
>> Brooklyn will do the interaction with the OAuth server to obtain a token,
>> which it will return to the br tool (in the form of a JWT token). Then br
>> can store that in its local .brooklyn_cli file. What is the REST request
>> to be used for that login action?
>>
>> Subsequently all requests will be sent with
>>
>> Authorization: Bearer xxxxx.yyyyyy.zzzzz
>>
>> Where x.y.z is the JWT token.
>>
>> Is the above understanding right?
>>
>> How will your design support br being able to log in to some Brooklyn
>> servers without OAuth configured, and others that do use OAuth?
>>
>> Just a couple of thoughts, but I’m keen to see this. Happy to review any
>> early draft pull requests you may have.
>>
>> Regards
>> Geoff
>>
>>> On 21 May 2019, at 15:11, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
>>>
>>> Hello all
>>>
>>> I'm continuing with changes for allow oauth authentication in Apache
>>> Brooklyn. I'm working now on the BR command line tool.
>>> The initial idea is send the JWT access token in the headers instead send
>>> the basic authentication header when the token is available after
>> execute a
>>> login command to get the token.
>>>
>>> I'll modify the BR login command to allow inject headers and store it on
>>> the yaml file and sent on the API calls. Is a new Authorization header is
>>> available sent it rather than the default authentication.
>>>
>>> Any concerns about this approach? I'm fully open to any idea.
>>>
>>> Best regards.
>>>
>>> Juan
>>>
>>> --
>>> Juan Cabrerizo
>>> Software Engineer
>>>
>>> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
>>> E: juan@cloudsoft.io
>>> L: https://www.linkedin.com/in/juancabrerizo/
>>>
>>> Need a hand with AWS? Get a Free Consultation.
>>
Re: Allowing OAUTH in Apache Brooklyn Client (BR)
Posted by Juan Cabrerizo <ju...@cloudsoft.io>.
Hi Geoff. Thanks your your thoughts.
As different oauth providers can implement login in very different ways,
for the moment I'm bypassing the process for request the token. Once the
user get it with an external mechanism, he can add it when do login with br.
As you said, once you use the token for login, you need sent it on all REST
calls for authentication.
And also, I added a new parameter for do not request for user and password.
If it is added, br won't sent the current basic authentication header.
The command will be executed as:
br login http://server:port --noCredentials --header 'Authorization: Bearer
xxxxx.yyyyyy.zzzzz' --header 'OtherHeader=headerValue'
This execution will crate this persisted yaml:
{
"credentials": {
"http://localhost:8081": "Og=="
},
"credentialsRequired": false,
"headers": {
"Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
"OtherHeader": "headerValue"
},
"skipSslChecks": false,
"target": "http://localhost:8081"
}
If you don't add this new parameter, the behavior will be the same as
before, so it won't affect that not use oauth.
I defined for the moment `headers` and `credentialsRequired` as global (no
related to any target) as is for `skipSslChecks`
Other more ambitious change could be modify the structure to something like:
{
"servers": {
"http://localhost:8081":{
"credentials":"Odddg=="
},
http://remote1:8081":{
"credentials":"xxxxx=="
},
http://remote2:8081":{
"credentialsRequired": false,
"headers": {
"Authorization: Bearer xxxxx.yyyyyy.zzzzz": "",
"OtherHeader": "headerValue"
},
},
},
"skipSslChecks": false,
"target": "http://localhost:8081"
}
I already have the first version working and i'm testing it in a couple of
environments, probably I'c create a PR this week. I'm not sure if it worth
make more changes.
Thanks again for your ideas.
Regards
Juan
On Wed, 22 May 2019 at 23:12, Geoff Macartney <ge...@gmail.com>
wrote:
> Hi Juan,
>
> If I understand you right you mean that the login command will do a
> request to Brooklyn, sending the username and collected password, and
> Brooklyn will do the interaction with the OAuth server to obtain a token,
> which it will return to the br tool (in the form of a JWT token). Then br
> can store that in its local .brooklyn_cli file. What is the REST request
> to be used for that login action?
>
> Subsequently all requests will be sent with
>
> Authorization: Bearer xxxxx.yyyyyy.zzzzz
>
> Where x.y.z is the JWT token.
>
> Is the above understanding right?
>
> How will your design support br being able to log in to some Brooklyn
> servers without OAuth configured, and others that do use OAuth?
>
> Just a couple of thoughts, but I’m keen to see this. Happy to review any
> early draft pull requests you may have.
>
> Regards
> Geoff
>
> > On 21 May 2019, at 15:11, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
> >
> > Hello all
> >
> > I'm continuing with changes for allow oauth authentication in Apache
> > Brooklyn. I'm working now on the BR command line tool.
> > The initial idea is send the JWT access token in the headers instead send
> > the basic authentication header when the token is available after
> execute a
> > login command to get the token.
> >
> > I'll modify the BR login command to allow inject headers and store it on
> > the yaml file and sent on the API calls. Is a new Authorization header is
> > available sent it rather than the default authentication.
> >
> > Any concerns about this approach? I'm fully open to any idea.
> >
> > Best regards.
> >
> > Juan
> >
> > --
> > Juan Cabrerizo
> > Software Engineer
> >
> > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
> > E: juan@cloudsoft.io
> > L: https://www.linkedin.com/in/juancabrerizo/
> >
> > Need a hand with AWS? Get a Free Consultation.
>
>
--
Juan Cabrerizo
Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
E: juan@cloudsoft.io
L: https://www.linkedin.com/in/juancabrerizo/
Need a hand with AWS? Get a Free Consultation.
Re: Allowing OAUTH in Apache Brooklyn Client (BR)
Posted by Geoff Macartney <ge...@gmail.com>.
Hi Juan,
If I understand you right you mean that the login command will do a request to Brooklyn, sending the username and collected password, and Brooklyn will do the interaction with the OAuth server to obtain a token, which it will return to the br tool (in the form of a JWT token). Then br can store that in its local .brooklyn_cli file. What is the REST request to be used for that login action?
Subsequently all requests will be sent with
Authorization: Bearer xxxxx.yyyyyy.zzzzz
Where x.y.z is the JWT token.
Is the above understanding right?
How will your design support br being able to log in to some Brooklyn servers without OAuth configured, and others that do use OAuth?
Just a couple of thoughts, but I’m keen to see this. Happy to review any early draft pull requests you may have.
Regards
Geoff
> On 21 May 2019, at 15:11, Juan Cabrerizo <ju...@cloudsoft.io> wrote:
>
> Hello all
>
> I'm continuing with changes for allow oauth authentication in Apache
> Brooklyn. I'm working now on the BR command line tool.
> The initial idea is send the JWT access token in the headers instead send
> the basic authentication header when the token is available after execute a
> login command to get the token.
>
> I'll modify the BR login command to allow inject headers and store it on
> the yaml file and sent on the API calls. Is a new Authorization header is
> available sent it rather than the default authentication.
>
> Any concerns about this approach? I'm fully open to any idea.
>
> Best regards.
>
> Juan
>
> --
> Juan Cabrerizo
> Software Engineer
>
> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
> E: juan@cloudsoft.io
> L: https://www.linkedin.com/in/juancabrerizo/
>
> Need a hand with AWS? Get a Free Consultation.