<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 19/11/15 14:59, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAfTTGvGWG1_5vuTWAFzxQp7N=ZQsXiOvymZgp_bj4+msA@mail.gmail.com"
type="cite">
<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>
</blockquote>
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:<br>
- IdentityProviderModel has: internalId + alias<br>
- UserFederationModel has: id + displayName<br>
- role has: id + name + description (Name is unchangeable and not
localized, so have different meaning then "name" for client etc)<br>
<br>
But not sure what is "Display Class" . Is it the same thing like
"description" ? I would personally use:<br>
- ID<br>
- displayName<br>
- description<br>
<blockquote
cite="mid:CAJgngAfTTGvGWG1_5vuTWAFzxQp7N=ZQsXiOvymZgp_bj4+msA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<blockquote
cite="mid:CAJgngAfTTGvGWG1_5vuTWAFzxQp7N=ZQsXiOvymZgp_bj4+msA@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 19 November 2015 at 14:49, Bill
Burke <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
href="http://localhosT:8080/employee-sig"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://localhosT:8080/employee-sig">http://localhosT:8080/employee-sig</a></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-likeadmin<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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://bill.burkecentral.com" rel="noreferrer"
target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>