Re: [keycloak-dev] Client ID and Client ClientID - I propose we remove one

On 19/11/15 14:59, Stian Thorgersen wrote: How about: * IDs are usually generated, but can be specified. It should not be possible to change them though * Instead of alias, name and all other ways of setting a human readable name we add Display Name and Display Class So this will be for all other objects, not just clients? Again +1 as currently it's mess. Various objects have various "names" for kind of same thing. Or even more they have same names, for different things. For example: - IdentityProviderModel has: internalId + alias - UserFederationModel has: id + displayName - role has: id + name + description (Name is unchangeable and not localized, so have different meaning then "name" for client etc) But not sure what is "Display Class" . Is it the same thing like "description" ? I would personally use: - ID - displayName - description

Not sure how to deal with migration, but if we agree on those points, then we can figure that out On 19 November 2015 at 14:49, Bill Burke <bburke(a)redhat.com&gt; wrote: > One more thing. Another problem is that if you switch to ID for > everything, then demos etc. will no longer run out of the box and you'll > have to modify adapter configuration to set the newly generated DB id. > Really, any piece of configuration that references things by client ID > will no longer work. > > So, there's really 2 issues: > > * Using ClientID in admin-console URLs doesn't work well as the client > IDs could have '/' characters in them > * Using ID only messes up pre-defined, pre-packaged adapter config and > you have to edit these files after the keycloak DB is set up. > > On 11/19/2015 8:40 AM, Bill Burke wrote: > > We currently actually have 3 client identifers: ID, ClientID, and Name. > > > > Also, I think there are a lot of duplicate clientID names between > > realms. i.e. "admin-console" "broker", etc... > > > > A search by clientID is (realm + clientID). > > > > Marek is right about why I switched everything to ID in the admin > > console. For SAML I just didn't want to add yet another client > > identifier since we already had 3. > > > > On 11/19/2015 7:52 AM, Marek Posolda wrote: > >> +1 for this change. > >> > >> I am just not sure if we should set the "id" to the current value of > >> "client-id" ? Few things to note: > >> > >> - SAML clients currently use clientId in form of URL. For example in > >> SAML demo there are clientIds like " > <http://localhosT:8080/employee-sig>http://localhosT:8080/employee-sig&... > >> . I don't know if it's requirement, maybe it's possible to solve it > >> somehow (ie. introduce different attribute for SAML client to store > >> these URLs). But from what I remember, Bill changed admin console to > use > >> "id" instead of "clientId" because there were issues with URL-likeadmin > > >> clientId in admin console . So if we overwrite the "id" with current > >> "client-id" the issue will be back. > >> > >> - Migration might be a pain. Many tables (roles, protocolMappers, user > >> consents, offline clientSessions ...) references client by "id" . > >> Overwriting "id" with "client-id" means that we will need to change all > >> those DB records. And there are things like foreign keys etc... > >> > >> Shouldn't do vice-versa and just remove current "client-id" and ask > >> people to update their keycloak.json adapter configurations? On the > >> other hand, removing "client-id" might break migration of JSON exported > >> realms as the JSON entities are using "client-id" for referencing > client. > >> > >> It seems the migration will be a pain regardless of whatever direction > >> we choose :-( > >> > >> Marek > >> > >> On 16/11/15 14:54, Stian Thorgersen wrote: > >>> We have both "id" and "client-id" for clients in Keycloak at the > >>> moment. This seems unnecessary and complex. > >>> > >>> The model can retrieve clients on either value. In token endpoints the > >>> "client-id" is used. In admin endpoints the "id" is used. > >>> > >>> Also, in most cases it would be simpler for users to just have a > >>> generated id than having to come up with one themselves. The id > >>> doesn't have to be human readable either as we have name for that. > >>> > >>> OpenID Connect expects "client-id" to be generated by the IdP and > >>> can't be changed once created. > >>> > >>> I propose we remove "client-id" and only keep id. > >>> > >>> For migration of existing clients we would set the "id" value to the > >>> current value of "client-id". This would require no changes to adapter > >>> configs. When creating new clients from the admin console we would not > >>> allow setting the "client-id", instead just display it after the > >>> client was created. When importing clients it would be possible to set > >>> the id (and for backwards compatibility we would set "id" equal to the > >>> "client-id" field. > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev