OIDC Configuration Parsing Error and Key Mismatch in iRODS HTTP API #227
Comments
|
We've fixed it. The issue was related to the well_known_uri path. Apparently, there's no need to specify it because it is retrieved directly from the config_host path. I haven't checked your code, but you are probably parsing the OIDC well-known endpoint by default on the OIDC provider hostname. I've noticed that you updated the OIDC config keys, and in version 0.2.0, it will be clearer for sure. However, at the moment:
I have another question: since iRODS user mapping with the OIDC provider user is not yet available in the config.json, how can it be set?" |
Currently, the server looks for an
That is correct, we automatically add |
Since Indigo IAM is not allowing to set custom claim would it be possible to map the |
|
@bl000m A couple questions ... Q. By iRODS: latest, are you talking about iRODS 4.3.1? |
|
Hello |
|
0.2.0 is now released. https://github.com/irods/irods_client_http_api/releases/tag/0.2.0 Please let us know if it works for the |
|
Hello, Here is the decoded AT here below the iRODS http api instance oidc config: To give you some context:
NB I know that you suggest to set the redirect uri as to the HTTP API authentication point as it is specified here
but in our case it doesn't work that way. So we handle the authorization grant exchange for the access token on the backend of the portal FITS, that we would like to be the entrypoint for the user's iRODS via the HTTP API. Please let me know of you want me to share the php code handling that, if could help Please tell me if you need more details. Thanks for your help |
This is because the iRODS HTTP API does not act as an OAuth protected resource at this moment. Currently, the HTTP API needs the authorization code, since we assume we get it back after the user authenticates. |
May you be more precise about this flow? How can we make the engine work at the moment ? From what I understand, in order to have the oidc provider claim mapped to the irods_user_claim you need an AT containing that claim. The authorization code sent back after authorization by the oidc provider doesn't contain it directly. And in the case of Indigo IAM you get this kind of AT if you add the scope "profile" when creating the url based on oidc provider url for user authorisation. Once the user authorise irods, the authorization code sent back to the redirect uri has to be sent back to the oidc provider for it to generate the token. I don't see how the iRODS http api could generate the token itself without interacting with oidc provider. |
The
That is correct. We take the authorization code and exchange it at the OpenID Provider's token endpoint for something like the following: {
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "very.long.jwt"
}The above JSON example is taken from the OpenID Specification, with a change to the From there, we extract the
That is correct. The iRODS HTTP API does exchange the authorization code at the OpenID Provider's token endpoint. The iRODS HTTP API does not accept Access Tokens for endpoint authorization at this moment, only 'iRODS HTTP Tokens'. |
and
Not sure to understand. Based on what is specified in your repo README (below), the value of From the README:
|
|
The following entry in the iRODS HTTP API The value associated with this |
Okay, thanks for clarifying. So, a custom OIDC claim is needed for the mapping to occur. I had interpreted it differently. Unfortunately, the Indigo IAM OIDC provider doesn't currently allow the creation of custom claims such as |
|
If I'm reading your statement correctly.... and you have a value coming from the OIDC provider that you want to use as the iRODS username... then I think this is what you put in your This will look for a key/claim named |
Yes it's exact. Thanks for confirming that |
|
Ah, very good. Please let us know if this works as you expected/wanted. |
|
@bl000m We've just released HTTP API 0.3.0. Please give it a try and let us know if it resolves your issue. |
|
@korydraughn thank you for letting us know. Shouldn't these values be dynamically extracted from the OIDC provider? |
|
The hard-coded values are for demonstration purposes. You can change/remove those mappings to what you like. That must be done for each user. For example: "user_attribute_mapping": {
"alice": {
// "alice" is identified as the user if and only if these
// key-value pairs exist in the OIDC response.
"oidc_prop_1": "value_1",
"oidc_prop_N": "value_N",
"email": "alice@example.com"
},
"bob": {
// "bob" is identified as the user if and only if these
// key-value pairs exist in the OIDC response. Notice how
// "bob" requires one additional key-value pair.
"oidc_prop_1": "value_1",
"oidc_prop_N": "value_N",
"special_prop": "value"
},
"rods": {
// Same thing is true for "rods".
"sub": "sub_value"
}
},So the answer to your question is yes. |
If I understand this correctly, then the answer is no rather than yes: the values must be hardcoded for each user and are not automatically extracted from the OIDC provider access token claims. If this assumption is correct, and considering that we will need to map thousands of users in the long term, manually doing so for each user is not practical. In this case, if I refer to the documentation in the "iRODS as an OAuth Protected Resource" section:
If I am understanding correctly, we can proceed at this point with just using |
|
Correct. @MartinFlores751 Thoughts? The conversation starts at #227 (comment). |
|
@korydraughn Your explanation of
Yes, you should be able to use
I'm curious about the use case you had in mind for this. Did you want to extract some values and do something with them in the iRODS HTTP API?
That is correct. In order to map a user using |
|
Thanks for the clarification |
|
Will close if there is no other points of discussion. Of course, @bl000m please continue trying your use cases against 0.3.0 and we'll fix/add anything for 0.4.0. Thanks everyone. |
Feature
OIDC for Single Sign-On with Indigo IAM OIDC Provider
Both myself and @sigau are encountering issues while configuring the OIDC settings. The config.json has recently changed, and if we retain the previous version:
Executing
docker run --rm --name irods_http_api -v ./config.json:/config.json:ro -p 9000:9000 irods/irods_http_apiresults in the following output, where the HTML of the OIDC provider login page is parsed as if it were the expected JSON:We encounter the following issue:
As if the
oidckey in config.json wasn't been updated toopenid_connectMay you please help understanding where we are wrong
Thanks
iRODS Version, OS and Version
iRODS: latest,
OS: Ubuntu 22.04
The text was updated successfully, but these errors were encountered: