imaykay
commented
5 years ago Hi @mcjaeger, everything sounds correct to me. Maybe just one refinement to the last bullet point in your list: The named Oauth credentials are "just" a valid Oauth access token that can be used for access until its given validity is reached.
So, just let us know which of the given two solutions you prefer. As discussed, both have advantages and disadvantages. Main points are:
Custom solution: user attribute
pro: faster to implement and easier to use con: no standard and custom tailored
Standard solution: oauth client workflow
pro: official standard for that use case con: more complicated to implement for us and each client
mcjaeger
Background
Some discussion from a couple telcos have covered to re-engineer the write access over the REST API to the SW360 system. Currently, there are the following two main authentication methods:
Currently, write access over the REST API is possible the same way as using the UI in the browser. Since a person has written a selenium-based remote control for SW360 (before the REST API was available) a separate restriction of the REST API which is not there in the Web UI is questionable.
The access key generation (in the user's preference section) allows for generation of read access only or read/write access.
New Motivation
Now another problem has emerged: not every user shall be able to write the SW360 using the REST API. rather the users who can write to the SW360 shall be elevated only when they need to write and their writing REST client code is OK.
Otherwise, users started writing a number of not-so-cool data sets which do not contain useful information (component name and version only, etc) and created entries are also not checked for duplicates.
Idea is to have persons tested their write clients using the SW360 REST API in a staging environment. Then, they could be granted for productive use.
Possible approaches
In the discussions, several approaches were evaluated:
Every user record could have an additional attributes, similar to the information about enabling mail sendings or not, an attribute "enabling write access". Based on this attribute, the write access could be checked accordingly: by disabling the generation of write-allowing access keys, or when accessing the REST API, or both. An admin UI allows for setting the users write-ability using the REST API, meaning setting the attribute in the user record.
Using the Oauth consumer token for clients: In the Oauth workflow, two authentication tasks take place: one is for the user (and the application checks according for visibility rights for projects, for example), and another is the client software (client id and client secret in Oauth terminology). Accordingly, the new functionality could be an extension to manage clients. REST API write access could be controlled by issuing consumer tokens. Currently, the application supports only one pair of client id and client secret.
Using the Oauth workflow rises the question on how to to actually perform the user authentication, if the SW360 uses an external single sign on system (and the SW360 itself does not hold any authentication informatio). The authorization server cannot authenticate the user itself, because the SW360 facilities just do not have information or an Oauth identity provider to refer to.
The solution could be to generate an URL, which a user must open to login to the SW360 using the signle sign on. Then the necessary Oauth user-specific credentials can be shown in the Web UI. Calling the URL requires using the external sign sign on successfully in order to receive the necessary Oauth credentials from the SW360 for REST access.