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

[Stian Thorgersen]

On 19 November 2015 at 16:54, Marek Posolda <mposolda at redhat.com> wrote:

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

Display class is to set a custom css class. For example someone may want to
display a picture logo for a realm instead of text.


>
>
> 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 at redhat.com> 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 at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151123/c590dc30/attachment.html