[keycloak-dev] Filtering in New Account Console

Fri Oct 4 10:10:30 EDT 2019

My bad. I was thinking about comment 1, 2 and 3 from my first reply.

Let me re-read the whole thing again ;)

On Fri, 4 Oct 2019, 15:42 Bruno Oliveira, <bruno at abstractj.org> wrote:

> My comments were pretty much based on the items you mentioned:
>
> > 1) Limit the list to clients that are applications and that the user has
> access to (I suggested a fairly simple approach, which I believe should
> work)
>
> That wouldn't list the clients regardless if the user has access to
> them or not. So I'm not sure where the security issue is. Unless I'm
> missing something.
>
> > 2) Only list clients from active sessions - then add a follow-up for 1
> at some point in the future
> Yes, that's possible, but as you mentioned something to postpone
> unless badly needed. If we keep increasing the scope of what we aim,
> this may become an endless task.
>
> So here are my questions:
> - Are we in agreement that #1 should be part of our deliverable for
> the first release of the new account console and #2 implemented later?
> - If yes, are we ok about postponing pagination/filtering?
>
>
> On Fri, Oct 4, 2019 at 10:24 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > 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
>
>
>
> --
> - abstractj
>