3:07 p.m.
Yeah, support in protocol mapper is next step...
I can change existing UserAttributeMapper implementation to support
multiple values. I can add new on/off config property "Is multivalued" .
When off, it will read just single value of attribute from UserModel as
it's now. When on, it will read all the values and will use List in
access token (it will be list of all items of same type like
List<String> , List<Long> etc. Type is already provided by "Claim JSON
Type" config property).
Another possibility is to create another implementation of Protocol
mapper for support multivalued, but I don't think it's needed...
WDYT?
Marek
On 22/06/15 15:26, Bill Burke wrote:
I'm for #1. BTW, mappers don't support list at all they
assume user
attributes are just key/value pairs.
On 6/22/2015 9:14 AM, Marek Posolda wrote:
> LDAP allows to have multiple values of same attribute per single user.
> There is usecase to map all the values of some LDAP attribute to
> UserModel and then also to access token of particular user.
>
> For example, user has LDAP attribute "applications" with 2 values
> "sales" and "finance". Then in application there is code like
this:
>
> List<String> values =
accessToken.getOtherClaims().get("applications");
>
> which should then return 2 values "sales" and "finance" .
>
> The main issue here is mapping of multiple LDAP attributes to the
> UserModel, because "attributes" on UserModel currently support single
> String value per attribute. I can see 2 possibilities to address this:
>
> 1) Change "attributes" map on UserModel to be MultivaluedMap and support
> multiple String values per single key. This may require some migration,
> however for JPA it can be easy. We just need to support multiple values
> per single key and user in USER_ATTRIBUTES table (This breaks some
> normal form, but looks better to me than introducing another table like
> USER_ATTRIBUTE_VALUES as this will require migration changes again)
>
> 2) Use some delimiter for UserModel attribute value. So in previous
> example, the value of attribute "applications" on the user will be
> "sales###finance" (assuming that ### is delimiter). Then there will be
> protocol mapper, which will be able to parse delimiter and create again
> 2 values "sales" and "finance" to be used in access token.
>
> I am slightly for using (1) . What do you think? Any better ideas?
>
> Thanks,
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>