[keycloak-dev] Filtering in New Account Console

Fri Oct 4 10:53:09 EDT 2019

On Fri, 4 Oct 2019, 16:31 Stan Silvert, <ssilvert at redhat.com> wrote:

> On 10/4/2019 8:49 AM, Bruno Oliveira wrote:
> > 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)?
> I think we still need filtering and pagination.  Correct me if I'm wrong
> but someone could still have 20 to 40 apps that they have access to?
>
> The pagination doesn't have to be that sophisticated if we are talking
> about a total number under 100.  It could be just implemented as next
> and previous page like Pedro did for the Resource API.
>

>From past experience someone always have more than we think ;)

> >
> >
> > 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
>
>
>