[keycloak-dev] Client ID and Client ClientID - I propose we remove one
Bill Burke
bburke at redhat.com
Thu Nov 19 13:26:09 EST 2015
On 11/19/2015 9:58 AM, Stian Thorgersen wrote:
>
>
> On 19 November 2015 at 15:43, Bill Burke <bburke at redhat.com
> <mailto: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.
>
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.
>
> 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 didn't even try to see if that worked. The issue is that there are
additional endpoints after the path:
.../children
.../composites
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.
> ??
>
> 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
>
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.:
GroupRepresentation topGroup = realm.getGroupByPath("/the/top");
List<RoleRepresentation> roles = new LinkedList<>();
roles.add(topRole);
realm.groups().group(topGroup.getId()).roles().realmLevel().add(roles);
Alternatively we could add links to the GroupRepresentation like 'self'
that points to the resource endpoint.
>
>
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list