On 19/11/15 14:59, Stian Thorgersen wrote:
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: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
- 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@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.
>> "id" instead of "clientId" because there were issues with URL-likeadmin
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
>> 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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________ keycloak-dev mailing list keycloak-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev