-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion on API access mechanism #24
Comments
As in Follow-up meeting #8, APi is to be considered as 2-legged access token. @bigludo7 is it required any modification in the API spec? |
@jgarciahospital I think we are good as we have:
To be 100% sure adding @AxelNennker to get his feedback |
I just heard that this QoD PR is the currently expected way to define security schemas: https://github.com/camaraproject/QualityOnDemand/pull/295/files As far as I understood openID (as in the QoD example) automatically means 3-legged. So, since pplDensity is client-credentials it should not use openID. Also a purpose and scope must be indicated. However, my interpretation can be inaccurate. |
OIDC is generally including both options, and it's generically included in the APIs where the option is opened, as the rule that applies depending on each region-regulation is that: It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control. So, up to know, we consider that the generic reference to OIDC is ok for this API, as also it's only considering Scopes (not PI scopes), but I agree that maybe commonalities or Identity&Consent should also consider this situation where the API is never considered as 3-legged at all. If that is finally agreed we can update based on commonalities. |
To be considered in next I&C release as current discussions are already closed. OpenIDConnect is defined as the generic auth, which in this case implies clientCredentials. @gregory1g @bigludo7 is that ok? |
@jgarciahospital For me this is OK for this release. We could stick with the 'CAMARA Statement' on this for this API. |
Putting some info from camaraproject/IdentityAndConsentManagement#157 here. My understanding is that
is the default security scheme Camara APIs should use. Especially if personal information is involved in the API. OIDC is a profile of OAuth2 and OIDC does not forbid OAuth2 client credentials. But, I find that always just specifying There might be endpoints that use CIBA and then an SMS is sent to the authentication device. But a client might reject CIBA because of the user experience. There might be one endpoint that is OIDC protected and a different one that is protected by CIBA. If an API or some of its endpoints do not involve user information than OAuth2 client credentials is totally fine and the API should be able to express that. Which I think is much more meaningful than using the ICM I think TSC did not forbid the possibility of defining other security schemes. I think that TSC decided that for now discovery is the way to go for OIDC. I want to state that I fully support the decision to use the openid security in all APIs and endpoints that involve personal information. |
I do agree with @AxelNennker. We have discussed and agreed that this API must be exposed using client credentials - this design decision must be documented in the API. |
Since I&CM group is not considering it, I'd prefer to stick in the current official WoW which is still generic OIDC, waiting for the next guidelines in the next meta release. Proposal is then to maintain current generic OIDC and adapt for following version, when I&CM and commonalities are clearer on this topic. |
@jgarciahospital I do not see a problem with adding e.g.
Whether or not client_credentials is allowed for a client is decided/granted at onboarding time. I would like to keep these onboarding concerns out of these technical documents. |
@AxelNennker while I understand it, I'm not comfortable modifying current version while there is not common agreement apart from the generic OIDC profiling. As soon as there is a mandate coming from TSC, I&CM or commonalities, we'll adapt as in any other required rule, but up to now I still suggest to maintain ourselves aligned with the current rules (of course, not asking other APIs to do the same). |
I am suggesting to add an oauth2 security scheme to Camara guidelines. |
Thanks Axel, we'll take a look on the proposal. When it gets clarified and agreed, we'll adapt this API and any other affected accordingly. |
Please chime in not only here but in the discussion in ICM and Commonalities. Do you or somebody else recollect? |
After DT-internal discussion we decided not to re-visit the TSC agreement from December. |
As discussed in Followup#9, API code is not to be modified, as following guidelines of I&CM of generic security scheme of OIDC, but documentation (as note) will be included to clarify this exact case (2-legged as no personal information). |
You appear to be making an implicit assumption that an API provider can only provide a single OIDC discovery URL that is common to all APIs. I didn't think that was the case - I see no reason why the So an API provider could specify:
In this case, the configuration would only list |
I know that. You could even go further and, an API with several endpoints could even have an endpoint-dependent meta-data url
The text in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#use-of-openidconnect-for-securityschemes is this:
Which makes the assumption that openIdConnectUrl is the discovery endpoint of the API provider. In Keycloak the Camara admin would then need to create a separate realm for each API, I think. The ICM guidelines mandate that there is exactly one security scheme. I think, that specifying different discovery URL whether OIDC or CIBA or client credentials be used is a hack. If you think this is the way to go then we should have guidelines regarding this in ICM https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#use-of-openidconnect-for-securityschemes |
That wasn't my proposal at all. The proposal is that the discovery endpoint be API specific (not authentication scheme specific). If an API implementation supports or requires multiple authentication schemes, then the discovery endpoint for that API will list all of these. |
@AxelNennker @eric-murray I think this is a pretty interesting discussion that should be handled in a broader forum than PopulationDensityData API. Can you please continue the conversation in an ad-hoc issue in I&CM? |
I created camaraproject/IdentityAndConsentManagement#176 in ICM after the TSC meeting. |
Thanks @AxelNennker As agreed during Population Density Meeting for this APi version:
#30 includes such changes |
During followup#7, discussion about the usage of 2-3 legged access tokens for this API(s) was raised as AoB.
Offline feedback to be provided.
The text was updated successfully, but these errors were encountered: