Repository navigation
question: keycloak backend for sw360 // clarity around -client_id and -client_secret聽#245
Description
Activity
Hi @brandon1024,
support for Keycloak credentials is fully implmented, see the chnagelog entry for version
2.12.0.dev1:
New options -client_id and -client_secret to support dynamic token generation with the new SW360 backend >= 20The other options like
-tand-oastill exist, because there are still people using them.I saw that -- what's unclear is how scopes are defined. See my comment above:
I noticed in #238 that some support was added, introducing the -client_id and -client_secret flags. However, it's not clear how to configure additional scopes.
What kind of scopes do you want to configure? The only useful scope I see in the documentation is to differ between read-only and WRITE tokens. For that, CaPyCli current hard-codes this as needed, compare e.g. https://github.com/sw360/capycli/blob/v2.12.0/capycli/bom/map_bom.py#L961 vs, https://github.com/sw360/capycli/blob/v2.12.0/capycli/bom/create_components.py#L804.
Note that there's currently unnecessary code duplication regarding the login, which is addressed by @dhruvv16-hash in #242, currently in review.
Also note that I've worked on a slight improvement of token auth documentation, see #240.
Reacted by Brandon RichardsonI haven't found much supporting documentation, but I know I'll need WRITE and READ for some operations. If the subcommands hardcodes the scopes, that works for me and answers my questions.
Thanks for the clarification. I'll give it a try and report back 馃憤
Yes, as there were quite some stability issues with SW360 v20 and some details were not clear, we only started to work on the sw360python and Capycli support quite late, so all of that was a bit rushed, so expect some improvements and stabilization to happen in that area, you might also find the discussion in #240 interesting. And as always, any contributions or concrete ideas for improvement are highly welcome! :-)
Reacted by Brandon RichardsonI just added a small note to Readme.md in #240 clarifying that CaPyCli will request a read or write token as needed. So I'd close this for now as I don't see any concrete topic for us here any more, but please report back on your findings, @brandon1024 and feel free to reopen if you still see need for improvement beyond #240!
Reacted by Brandon RichardsonAnd I'd be happy if you could check my Readme.md updates in https://github.com/sw360/capycli/pull/240/changes#diff-1550ec65ac92f65817fc28928dfef526912b5f52356ff43651369bae92f56031 and let me know there if you still see the need for more dicussion in Readme or a separate document!
Will do, thanks for the help Gernot!
Adjusted our pipeline configuration to configure client IDs and secrets, seems to be working well :-)
Hello 馃憢
I'm looking to get a bit more clarity around the changes which have been implemented in capycli to support the new KeyCloak backend for SW360. I scanned through the project documentation but couldn't find anything which describes the new OAuth flow.
I'd like to move away from the classic long-lived token configuration (the classic
-oa -t <token>) in our license clearing automation pipelines, and start exchanging client credentials for short-lived tokens instead. I'd also like to avoid configuring credentials or tokens at the command line, for all the reasons @gernot-h summarized nicely in #238 (comment).Exchanging client credentials for a token manually is pretty straightforward, but it's not ideal. I'd like for capycli to exchange the credentials for me, to avoid needing to have curl and jq installed.
I noticed in #238 that some support was added, introducing the
-client_idand-client_secretflags. However, it's not clear how to configure additional scopes.Thanks!