<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">+1 for this change. <br>
<br>
I am just not sure if we should set the "id" to the current value
of "client-id" ? Few things to note:<br>
<br>
- SAML clients currently use clientId in form of URL. For example
in SAML demo there are clientIds like
<a class="moz-txt-link-rfc2396E" href="http://localhosT:8080/employee-sig">"http://localhosT:8080/employee-sig"</a> . 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.<br>
<br>
- 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...<br>
<br>
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.<br>
<br>
It seems the migration will be a pain regardless of whatever
direction we choose <span class="moz-smiley-s2"><span> :-( </span></span><br>
<br>
Marek<br>
<br>
On 16/11/15 14:54, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAfLSNkD-3HcKbbY6wUOC8-2_Tfj4A7LNKh1S-r1w5NydA@mail.gmail.com"
type="cite">
<div dir="ltr">We have both "id" and "client-id" for clients in
Keycloak at the moment. This seems unnecessary and complex.
<div><br>
</div>
<div>The model can retrieve clients on either value. In token
endpoints the "client-id" is used. In admin endpoints the "id"
is used.</div>
<div><br>
</div>
<div>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.<br>
<div><br>
</div>
<div>OpenID Connect expects "client-id" to be generated by the
IdP and can't be changed once created.</div>
</div>
<div><br>
</div>
<div>I propose we remove "client-id" and only keep id.</div>
<div><br>
</div>
<div>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.</div>
</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>