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