[keycloak-dev] Client ID and Client ClientID - I propose we remove one
Stian Thorgersen
sthorger at redhat.com
Thu Nov 19 09:58:43 EST 2015
On 19 November 2015 at 15:43, Bill Burke <bburke at redhat.com> wrote:
> FYI, there's other problems too. Built in clients are looked up via their
> hardcoded ClientIds "admin-console" "broker" etc, again because DB ids are
> generated.
>
> I just don't see how you can remove ID or ClientID. ID is URL friendly,
> ClientID isn't and needs to be encoded. ID is pretty much hidden from the
> user until they want to use the REST interface. If you remove ID from the
> REST interface then ClientID @PathParams are gonna have to be encoded which
> could be a real pain for users, especially ones using simple HTTP. While
> most libraries will encode query and form params, users will have to encode
> by hand other mechanisms.
>
For clients I was thinking we should remove ClientID, not ID. We'd allow
specifying the ID when creating a new client, but not changing it. The ID
would also have to be URL friendly.
>
> There's a similar problem with Groups. Groups are looked up via a "path"
> name "/parent/child" in the REST interface, then you have use the ID to
> reference the rest of the GROUP rest interface i.e. groups/{ID}/children.
>
> We'll have similar problems with role namespaces if you want to
> incorporate them into the REST interface.
>
> ClientId should be forced to become a URL friendly string (no special
> characters or '/' or "?", etc.). SAML can introduce an Issuer URL or
> something. After that, you can remove ID. That's the only solution I can
> see that will work well.
For groups and roles couldn't the ID be the full path? Then the REST
endpoints would be aware of "hierarchies" so you could just do:
get /auth/realms/groups/group-parent/group-child
And:
get /auth/realms/roles/role/path/to/role/myrole
??
I think the current approach of having REST endpoints that retrieve based
on ID is a pain point for a lot of users. They create a client with a named
client-id or role with a name, then have to use a different ID to retrieve
from the rest endpoints
>
>
>
> On 11/19/2015 8:59 AM, Stian Thorgersen wrote:
>
>> How about:
>>
>> * IDs are usually generated, but can be specified. It should not be
>> possible to change them though
>>
>> * Instead of alias, name and all other ways of setting a human readable
>> name we add Display Name and Display Class
>>
>> Not sure how to deal with migration, but if we agree on those points,
>> then we can figure that out
>>
>> On 19 November 2015 at 14:49, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>> One more thing. Another problem is that if you switch to ID for
>> everything, then demos etc. will no longer run out of the box and
>> you'll
>> have to modify adapter configuration to set the newly generated DB id.
>> Really, any piece of configuration that references things by client ID
>> will no longer work.
>>
>> So, there's really 2 issues:
>>
>> * Using ClientID in admin-console URLs doesn't work well as the client
>> IDs could have '/' characters in them
>> * Using ID only messes up pre-defined, pre-packaged adapter config and
>> you have to edit these files after the keycloak DB is set up.
>>
>> On 11/19/2015 8:40 AM, Bill Burke wrote:
>> > 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 <mailto:
>> keycloak-dev at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org <mailto: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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151119/2ae60342/attachment.html
More information about the keycloak-dev
mailing list