I didnât ask you to post those details. I just give you hint how to debug it safely. You are exposing your identity and credentials. Not clever idea.
t=2020-02-06T23:12:07+0000 lvl=eror msg=âAttribute not found when searching JSON with provided pathâ logger=oauth.generic_oauth attributePath=grafana_admin
t=2020-02-06T23:12:07+0000 lvl=eror msg=âAttribute not found when searching JSON with provided pathâ logger=oauth.generic_oauth attributePath=grafana_admin
I am just trying to figure out how the resourcePath is supposed to look like
Both use on http://jmespath.org/ and test/evaluate your role_attribute_path value.
Note 1: use 6.6.0+ because you may need https://github.com/grafana/grafana/pull/20300
Note 2: you may need to configure your Okta OIDC client, because only you know what is returned by Okta IdP; maybe some details useful for authorization are not returned
I donât agree. Each Identity Provider (IDP) can provide own custom payload in the access/id token. So your example will be valid only for Okta IDP users and very likely it wonât be valid for other IDP users. Also IDP administrator may configure custom payload, so there is no way where one example of role_attribute_path will cover all IDPs and all their configurations.
Iâm also using Okta OAuth2, and gopi1âs example seems like it should work because I can verify with the JMES tool on https://jmespath.org/ that the correct roles are being selected from the groups coming back from Okta, but Iâm getting the following debug message, and my user is getting a role of âviewerâ regardless of the group.
t=2020-10-21T23:11:46+0000 lvl=dbug msg="Syncing Grafana user with corresponding OAuth profile" logger=oauth
t=2020-10-21T23:11:46+0000 lvl=dbug msg="Syncing organization roles" logger=login.ext_user id=2 extOrgRoles=map[]
t=2020-10-21T23:11:46+0000 lvl=dbug msg="Not syncing organization roles since external user doesn't have any" logger=login.ext_use
Nevermind, it was a typo I just noticed it was not appearing as a config override in the logs like the other auth overrides were.
For anyone else running into this, if youâre configuring Grafana via environment variables, the role_attribute_path key should be GF_AUTH_OKTA_ROLE_ATTRIBUTE_PATH not GF_AUTH_ROLE_ATTRIBUTE_PATH.
thought Iâd just add this as it took quite a few hours to discoverâŚ
I followed current grafana keycloak instructions and its mentions creating clientId as grafana-oauth.
Short version⌠When you expose the roles in keycloak by going to the client scopes â roles â Mappers â client roles (ie enable Add to Id Token , Add to userinfo), the entry in the json returned by keycloak for roles will be in the format seen in the âToken Claim Nameâ field and the default is âresource_access.${client_id}.rolesâ
Its will be returned in the userinfo api like
The issue is that if you try to setup your role_attribute_path using âgrafana-oauthâ like below, the JMESPATH query will fail as it does NOT like the - in granfan-oauth.
Hope this helps. Took my hours to figure out that it was a JMESPATH query issue.
FYI⌠Its helpful to turn logging = debug as you can see the info returned from the get userInfo api. you can then see how you need to structure the role_attribute_path JMSEPATH query.