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

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 >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev