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.macart...@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 <j...@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: j...@cloudsoft.io
L: https://www.linkedin.com/in/juancabrerizo/
Need a hand with AWS? Get a Free Consultation.
