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)

Most upvoted comments

@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 😅