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 <[email protected]> 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 <[email protected]> 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: [email protected] > > 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: [email protected] L: https://www.linkedin.com/in/juancabrerizo/ Need a hand with AWS? Get a Free Consultation.
