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

[Bill Burke]

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"
> . 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-like
> 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