[keycloak-dev] Filtering in New Account Console

Fri Oct 4 09:24:05 EDT 2019

We're not on the same page. #2 is absolutely not redundant with #1. It is
both a security issue and a usability issue to list all applications
regardless if the user has access to them or not.

One more not devices page should not list applications with offline access
(offline sessions) those should be on app page (or a separate place?!?)

On Fri, 4 Oct 2019, 14:49 Bruno Oliveira, <bruno at abstractj.org> 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)?
>
>
> 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
>