[keycloak-dev] Filtering in New Account Console

[Bruno Oliveira]

I believe that we're all in agreement that we don't need pagination
for the Applications endpoint.

And I have the same impression as Stan, #1 makes perfect sense and
once it's done should make #2 redundant. If we are on the same page
about this, I can update
https://issues.jboss.org/browse/KEYCLOAK-5628.

Another question is: assuming that we implement #1. Do we still need
filtering (https://issues.jboss.org/browse/KEYCLOAK-11534)?


On Fri, Oct 4, 2019 at 8:59 AM Stian Thorgersen <sthorger at redhat.com> wrote:
>
> You can not have an application page in the new account console that lists every client there is in a realm. As I said a large portion of those will not be actual applications, and a portion will be applications that the user does not have access to.
>
> There's really two choices here:
>
> 1) Limit the list to clients that are actually applications and that the user has access to (I suggested a fairly simple approach, which I believe should work)
> 2) Only list clients from active sessions - then add a follow-up for 1 at some point in the future
>
> My preference here would be 1 for sure as if this is done right it would be a good value add for users to have a place to discover available applications.
>
> On Thu, 3 Oct 2019 at 11:54, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>> On 2019-10-03, Stian Thorgersen wrote:
>> > Simply returning all clients is not going to work for a few reasons:
>> >
>> > * It will return clients that are not applications/UIs
>> > * It can return applications the user doesn't have access to
>> > * There can be thousands (in fact we know about users with 10K+ clients)
>> >
>> > That means we need the following:
>> >
>> > 1) Limit clients returned by the REST endpoint to only those that are
>> > indeed applications/UIs
>>
>> That makes sense, at the same time, not part of our requirements into the
>> Jira: https://issues.jboss.org/browse/KEYCLOAK-5628.
>>
>> Doug is working on it, and if there's anything that has to change, I'd
>> suggest we bring this up in the same Jira.
>>
>> > 2) Limit applications to those the user has access to
>>
>> Same as my previous comment
>>
>> > 3) Support filtering and pagination (even though 1 and 2 most likely will
>> > significantly reduce the number of applications to 10s of applications, we
>> > still need to have pagination and filtering support)
>>
>> We have a Jira for filtering, but not for pagination.
>> See: https://issues.jboss.org/browse/KEYCLOAK-11534. But if you think
>> pagination should also be a part of it, please let us know. Just keep in
>> mind that this is not part of our plans at the moment.
>>
>> Do you really think we need to implement pagination for Applications
>> endpoint right now? Based on the requirements you described, I don't see
>> a user with 2000 applications. Just look at how many applications you
>> have linked into your GH or FB profile.
>>
>> Maybe this is something we could postpone? Unless I'm missing something,
>> I don't see a real need to do it right now.
>
>
> If you do 1 or 2 the list of applications available to any given user will be reduced significantly, so I'm fairly confident that pagination/filtering on the server-side can be postponed in that case.
>
>>
>>
>> >
>> > Some ideas on how we can achieve the above:
>> >
>> > 1) Figuring out what is indeed applications/UIs
>> >
>> > List applications that are added to open sessions, including the below:
>> >
>> > * All OIDC clients where: client.baseUrl != null && !client.bearerOnly
>> > * All SAML clients where: client.baseUrl != null**
>> >
>> > This will make sure we only include applications where the user can
>> > actually click on the application in the list to go to the application.
>> >
>> > ** Not sure if there's anything in addition to check for SAML
>> >
>> > 2) Limit applications to those the user has access to
>> >
>> > Not sure about this one as we don't really have an easy way to figure out
>> > if a user has access the an application or not. One idea would be to only
>> > include clients where user has at least one client role. Even if the
>> > application doesn't use client roles directly a "dummy" role can be created
>> > for this purpose by admins/developers.
>> >
>> > 3) Pagination and filtering
>> >
>> > All endpoints should support pagination and filtering by design. Pagination
>> > and filtering should be server-side (REST endpoint should provide according
>> > to our REST guidelines).
>>
>> +1 for most of the ideas, except for implementing pagination right now.
>>
>> >
>> > On Wed, 2 Oct 2019 at 19:11, Stan Silvert <ssilvert at redhat.com> wrote:
>> >
>> > > Specifically, we need to discuss filtering and pagination as it relates
>> > > to the "Applications" page:
>> > >
>> > > https://marvelapp.com/c90dfi0/screen/59942290
>> > >
>> > > The current design allows filtering by name and application type.
>> > >
>> > > However, Stian has pointed out that some customers will have thousands
>> > > of clients.  So this design might be unworkable.
>> > >
>> > > I don't want to go too far into the weeds right now because I want to
>> > > understand the problem better first.
>> > >
>> > > What is the use case when customers have many, many clients?
>> > >
>> > > How common is it to have many, many clients for a single user?
>> > >
>> > > What do those clients look like?
>> > >
>> > > What could we use to filter on?  The information we currently have on
>> > > the client side looks something like what you see here:
>> > >
>> > > https://marvelapp.com/c90dfi0/screen/59942292
>> > >
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > 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
>>
>> --
>>
>> abstractj



--
- abstractj