[keycloak-dev] Client ID and Client ClientID - I propose we remove one
Marek Posolda
mposolda at redhat.com
Thu Nov 19 10:54:22 EST 2015
On 19/11/15 14:59, 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
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:
- IdentityProviderModel has: internalId + alias
- UserFederationModel has: id + displayName
- role has: id + name + description (Name is unchangeable and not
localized, so have different meaning then "name" for client etc)
But not sure what is "Display Class" . Is it the same thing like
"description" ? I would personally use:
- ID
- displayName
- description
>
> 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-likeadmin
> >> 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
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151119/1fbb36f1/attachment-0001.html
More information about the keycloak-dev
mailing list