<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 November 2015 at 19:26, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 11/19/2015 9:58 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<br>
On 19 November 2015 at 15:43, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>> wrote:<br>
<br>
FYI, there's other problems too. Built in clients are looked up via<br>
their hardcoded ClientIds "admin-console" "broker" etc, again<br>
because DB ids are generated.<br>
<br>
I just don't see how you can remove ID or ClientID. ID is URL<br>
friendly, ClientID isn't and needs to be encoded. ID is pretty much<br>
hidden from the user until they want to use the REST interface. If<br>
you remove ID from the REST interface then ClientID @PathParams are<br>
gonna have to be encoded which could be a real pain for users,<br>
especially ones using simple HTTP. While most libraries will encode<br>
query and form params, users will have to encode by hand other<br>
mechanisms.<br>
<br>
<br>
For clients I was thinking we should remove ClientID, not ID. We'd allow<br>
specifying the ID when creating a new client, but not changing it. The<br>
ID would also have to be URL friendly.<br>
<br>
</span></blockquote>
<br>
Removing clientID doesn't work for built-in clients like account, broker, admin-console, etc. These all need to be located using a predetermined name. You'd have to figure out an additional alternative to refactor that.</blockquote><div><br></div><div>Is it not actually bad that they are located using predetermined names? If lookup is on id, you know for a fact that it's the correct client and not just something with the same name.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There's a similar problem with Groups. Groups are looked up via a<br>
"path" name "/parent/child" in the REST interface, then you have<br>
use the ID to reference the rest of the GROUP rest interface i.e.<br>
groups/{ID}/children.<br>
<br>
<br>
We'll have similar problems with role namespaces if you want to<br>
incorporate them into the REST interface.<br>
<br>
ClientId should be forced to become a URL friendly string (no<br>
special characters or '/' or "?", etc.). SAML can introduce an<br>
Issuer URL or something. After that, you can remove ID. That's the<br>
only solution I can see that will work well.<br>
<br>
<br>
For groups and roles couldn't the ID be the full path? Then the REST<br>
endpoints would be aware of "hierarchies" so you could just do:<br>
<br>
get /auth/realms/groups/group-parent/group-child<br>
<br>
And:<br>
<br>
get /auth/realms/roles/role/path/to/role/myrole<br>
<br>
</blockquote>
<br></span>
I didn't even try to see if that worked. The issue is that there are additional endpoints after the path:<br>
<br>
.../children<br>
.../composites<br>
<br>
And methods to add remove group children and role composites. I'm pretty sure there are some JAX-RS and/or regular-expression mapping issues with that. At least that's what I remember, might be a false memory.</blockquote><div><br></div><div>Didn't think of the additional stuff under each element. Even if it works it would be messy.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
??<br>
<br>
I think the current approach of having REST endpoints that retrieve<br>
based on ID is a pain point for a lot of users. They create a client<br>
with a named client-id or role with a name, then have to use a different<br>
ID to retrieve from the rest endpoints<br>
<br>
</blockquote>
<br></span>
The way it works for groups now is that i have a /group-by-path lookup mechanism which returns a GroupRepresentation, the id is extracted from that, then you invoke from there, i.e.:<br>
<br>
GroupRepresentation topGroup = realm.getGroupByPath("/the/top");<br>
List<RoleRepresentation> roles = new LinkedList<>();<br>
roles.add(topRole);<br>
realm.groups().group(topGroup.getId()).roles().realmLevel().add(roles);<br>
<br>
Alternatively we could add links to the GroupRepresentation like 'self' that points to the resource endpoint.<br></blockquote><div><br></div><div>I never liked it when we had multiple entry points to the same resource. What about using something like:</div><div><br></div><div>GET ../users?username=<myusername>&single=true</div><div>GET ../users?email=<myemail>&single=true<br></div><div><br></div><div>That returns a single UserRepresentation including 'self' (../users/<user-id>).</div><div><br></div><div>Same for groups:</div><div><br></div><div>GET ../groups?path=<url encoded path>&single=true</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<br>
<br>
On 11/19/2015 8:59 AM, Stian Thorgersen wrote:<br>
<br>
How about:<br>
<br>
* IDs are usually generated, but can be specified. It should not be<br>
possible to change them though<br>
<br>
* Instead of alias, name and all other ways of setting a human<br>
readable<br>
name we add Display Name and Display Class<br>
<br>
Not sure how to deal with migration, but if we agree on those<br>
points,<br>
then we can figure that out<br>
<br>
On 19 November 2015 at 14:49, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br></span><div><div class="h5">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>> wrote:<br>
<br>
One more thing. Another problem is that if you switch to<br>
ID for<br>
everything, then demos etc. will no longer run out of the<br>
box and you'll<br>
have to modify adapter configuration to set the newly<br>
generated DB id.<br>
Really, any piece of configuration that references things<br>
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<br>
the client<br>
IDs could have '/' characters in them<br>
* Using ID only messes up pre-defined, pre-packaged adapter<br>
config and<br>
you have to edit these files after the keycloak DB is set up.<br>
<br>
On 11/19/2015 8:40 AM, Bill Burke wrote:<br>
> We currently actually have 3 client identifers: ID,<br>
ClientID,<br>
and Name.<br>
><br>
> Also, I think there are a lot of duplicate clientID<br>
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<br>
the admin<br>
> console. For SAML I just didn't want to add yet another<br>
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<br>
current value of<br>
>> "client-id" ? Few things to note:<br>
>><br>
>> - SAML clients currently use clientId in form of URL.<br>
For example in<br>
>> SAML demo there are clientIds like<br>
"<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<br>
to solve it<br>
>> somehow (ie. introduce different attribute for SAML<br>
client to store<br>
>> these URLs). But from what I remember, Bill changed admin<br>
console to use<br>
>> "id" instead of "clientId" because there were issues<br>
with URL-like<br>
>> clientId in admin console . So if we overwrite the "id"<br>
with current<br>
>> "client-id" the issue will be back.<br>
>><br>
>> - Migration might be a pain. Many tables (roles,<br>
protocolMappers, user<br>
>> consents, offline clientSessions ...) references client<br>
by "id" .<br>
>> Overwriting "id" with "client-id" means that we will<br>
need to<br>
change all<br>
>> those DB records. And there are things like foreign<br>
keys etc...<br>
>><br>
>> Shouldn't do vice-versa and just remove current<br>
"client-id" and ask<br>
>> people to update their keycloak.json adapter<br>
configurations? On the<br>
>> other hand, removing "client-id" might break migration<br>
of JSON<br>
exported<br>
>> realms as the JSON entities are using "client-id" for<br>
referencing client.<br>
>><br>
>> It seems the migration will be a pain regardless of<br>
whatever<br>
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<br>
Keycloak at the<br>
>>> moment. This seems unnecessary and complex.<br>
>>><br>
>>> The model can retrieve clients on either value. In token<br>
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<br>
just have a<br>
>>> generated id than having to come up with one<br>
themselves. The id<br>
>>> doesn't have to be human readable either as we have<br>
name for that.<br>
>>><br>
>>> OpenID Connect expects "client-id" to be generated by<br>
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<br>
"id" value<br>
to the<br>
>>> current value of "client-id". This would require no<br>
changes to<br>
adapter<br>
>>> configs. When creating new clients from the admin<br>
console we<br>
would not<br>
>>> allow setting the "client-id", instead just display it<br>
after the<br>
>>> client was created. When importing clients it would be<br>
possible<br>
to set<br>
>>> the id (and for backwards compatibility we would set<br>
"id" equal<br>
to the<br>
>>> "client-id" field.<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> keycloak-dev mailing list<br>
>>> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br></div></div>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><span class=""><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br></span>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><span class=""><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br></span>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><span class=""><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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>
<br>
</span></blockquote><div class=""><div class="h5">
<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>
</div></div></blockquote></div><br></div></div>