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 <[email protected]> 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 <[email protected]> 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 < >> [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. > -- 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.
