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.
signature.asc
Description: Message signed with OpenPGP
