kanidm: oauth2_consent_scope_map not found in list of valid attributes
I did this
Upgrade from 1.1.0-rc.15 to 1.1.0-rc.16
I expected the following
It works as flawlessly as all past upgrades
Kanidm version details
- Output of
kanidm(d) version: kanidm 1.1.0-rc.16 - Are you running it in a container? If so, which image/tag?: No
- If not a container, how’d you install it: I use the NixOS package and service
- Operating System / Version (On Unix please post the output of
uname -a):Linux <host> 6.4.0 #1-NixOS SMP PREEMPT_DYNAMIC Sun Jun 25 23:29:58 UTC 2023 x86_64 GNU/Linux
Any other comments
Log output:
migrate_domain_4_to_5 [ 5.51ms | 0.69% ]
┝━ i [info]: Removing expired auth session | session_id: <uuid>
┝━ i [info]: Removing expired oauth2 session | o2_session_id: <uuid>
┝━ i [info]: Removing expired auth session | session_id: <uuid>
┝━ i [info]: Removing expired oauth2 session | o2_session_id: <uuid>
┝━ i [info]: Removing expired auth session | session_id: <uuid>
┝━ i [info]: Removing expired oauth2 session | o2_session_id: <uuid>
┝━ 🚨 [error]: oauth2_consent_scope_map <user>@<domain> - not found in the list of valid attributes for this set of classes ["account", "memberof", "object", "posixaccount", "service_account"] - valid attributes are ["account_expire", "account_valid_from", "api_token_session", "class", "description", "directmemberof", "displayname", "entry_managed_by", "gidnumber", "jws_es256_private_key", "last_modified_cid", "loginshell", "mail", "memberof", "name", "name_history", "oauth2_session", "primary_credential", "spn", "ssh_publickey", "unix_password", "user_auth_token_session", "uuid"] | event_tag_id: 1
┕━ 🚨 [error]: Schema Violation in validation of modify_pre_apply AttributeNotValidForClass("oauth2_consent_scope_map") | event_tag_id: 1
As far as I understand the source, oauth2_consent_scope_map is part of the account class, so I don’t quite understand why it fails.
Downgraded to 1.1.0-rc.15 for now, which starts successfully.
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Comments: 22 (16 by maintainers)
@Flakebi Really sorry for all the issues. 😦 We’ve improved a lot of how we do migrations now as a result of this incident.
After discussing in private with @tumbl3w33d I believe that client credentials grant will solve their issue once we have key domains in place. Since this won’t occur immediately, I will revert this change per option 3 so that existing use cases like @tumbl3w33d’s still function until we have a replacement available, and then they can smoothly transition.
Oh, I only noticed now that my account is a
service_account. That shouldn’t be 😅