Repository navigation
Replies: 5 comments 3 replies
|
I think option #2 makes sense too because long values are in theory more related to metadata than actual user-related attributes. For instance, we might want in the future to add metadata to attributes about their IAL (Identity Assurance Level) and the value should be a JSON. |
|
I just want to understand why these alts have already been disqualified apriori:
Sorry, I'm not well versed with Postgres indexes. Can you clarify, the consequence of this is it's impossible to Assuming that's true, questions:
My use case: Storing base64 encoded images in user attribute (OIDC picture; maybe storing images here is an abuse of kc, but regardless there are many other user attr use cases where >>256 is desirable). So I did this work around: I'm don't have a large user base and don't plan on doing any user attr search so just dropped the index but you can replace the current btree (?) index with a hash index |
|
Thank you @sgpinkus for the comment. While we need to extend a possible stored length of user attribute value, we still want to minimize an impact of migration of schema and records in the table. With user attributes the number of records could be really big and therefore dropping current index, changing a datatype in the database and creating new index could be potentially long blocking operation which could lead to major service disruption during migration. Keycloak also uses for the same reason a threshold for creation of new indices. Please see https://issues.redhat.com/browse/KEYCLOAK-11908 for detailed information about reasoning and #7657 for more implementation details. Did I understood it correctly that in your use-case you need to store long values, but you don't plan on doing any user attr search? Thanks a lot. |
|
The redhat link requires auth for access so didn't read, but I understand the gist - you have a policy around large table alters and re-indexing. Thanks.
Yes it's not important for the particular application. |
|
Database concerns aside, will there be any issues from increasing the length of the attribute value column when it comes to including a user's attribute within a token as a client scope? Aren't there limits to the size of a JWT token that could be hit if the attribute value is too long? |
|
There are size limits when you want to use it as a HTTP header aka bearer token. Still you can choose to add those values to a user info endpoint, or use them for internal purposes only. |
|
I have a similar issue with group attribute size. The need is to store a JSON object in the group attributes that contains all resources, roles, and scopes required to access an application. Unfortunately, due to size limitations, we couldn't proceed with this approach because of attribute constraints ( varchar(255) ). I have a question: is there any risk of regression if I alter the column size of the attributes table? |
Uh oh!
There was an error while loading. Please reload this page.
Currently User attribute value is limited to 255 characters. There has been several requests to address this issue: KEYCLOAK-9515, #9758.
Originally it was aimed to be resolved in new store, but after the decision about Discontinuation of Keycloak's Map Store it should be fixed in current store.
The API allows to search for users by their attributes and it uses exact search.
We've discussed the issue within the store team and we've identified two possible solution to the problem.
introduce two new columns to the table, one with blob which could handle long values and one with hash of it which would serve as an index. As we want to minimize an impact of migration we should keep storing short values in current column and store long values in new column. This solution would allow searching by any-length values and it'd require new index, which could be potentially long blocking operation during schema migration upon startup.
introduce one new column with blob for long values. The same applies here: we should keep storing short values in current column and store long values in new column. This solution would support storing long values and keep support searching by values up to current 255 characters, if longer then throw an exception.
As we are not aware at the moment of any use-case when a long-value search is required, only allowing storing it ... we've decided to go with an option 2 as a first step. It requires smaller change during a migration and if there is need to search by long attribute values, then we may switch to option 1. I'll be sending a PR with this change soon. It then would be available in Keycloak nightly to try it out.
I am searching for feedback whether there are use-cases to have a support for searching by long attribute values.
NOTE: There are also other entities which may have similar limitations, such as clients, roles, groups, realms. We may use the same approach for them as well, but it is out of scope for now. We want to gather feedback for users first.
All reactions