[keycloak-dev] Filtering in New Account Console

Fri Oct 4 10:16:55 EDT 2019

Okay, so I've re-read and we're on the same page I believe. Sorry for that
(trying to do to many things with too little time).

Option 1 limiting the list to real apps/UIs and those the user has access
to is what we should do since you are on board with this. Option 2 can then
be dropped completely as it was just a quicker temporary solution.

To limit to real apps in addition to what I listed before I would also only
include apps that have a display name set.

To limit apps that users have access to. Thinking about this some more and
the ideal I think would be to only list apps where user has at least one
client role. That may be a bit tricky though, but perhaps a smart query
could solve that? I'm open to other ideas here for sure though.

On Fri, 4 Oct 2019, 16:10 Stian Thorgersen, <sthorger at redhat.com> wrote:

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