Moving from v0.6.3 to master, it looks like the OpenID auth was refactored into jwtUtil. However, this no longer works with providers that do not use unique_name by default such as Google. In v0.6.3, any valid claim was used as the username, while in v0.7.0 only the claim unique_name is allowed to be the username. See,
|
for name in claims: |
|
log.debug(f"looking at claim: {name}") |
|
if name in jwt_decode: |
|
value = jwt_decode[name] |
|
log.debug(f"got value: {value} for claim: {name}") |
|
if name == "unique_name": |
|
username = value |
|
elif name == "appid": |
|
pass # tbd |
|
elif name == "roles": |
|
roles = value |
|
else: |
|
log.info(f"ignoring claim: {name} with value: {value}") |
|
else: |
|
log.debug(f"claim: {name} not found in bearer token") |
The v0.6.3 behavior wasn't great so I understand why it was changed, but this needs to be configurable. Possible options:
- The first listed claim is used as the username field (possibly only if
unique_name isn't present)
- Add a new config option
openid_username_claim and maybe also openid_roles_claim
Moving from v0.6.3 to master, it looks like the OpenID auth was refactored into jwtUtil. However, this no longer works with providers that do not use
unique_nameby default such as Google. In v0.6.3, any valid claim was used as the username, while in v0.7.0 only the claimunique_nameis allowed to be the username. See,hsds/hsds/util/jwtUtil.py
Lines 177 to 191 in 9e1f081
The v0.6.3 behavior wasn't great so I understand why it was changed, but this needs to be configurable. Possible options:
unique_nameisn't present)openid_username_claimand maybe alsoopenid_roles_claim