Re: [keycloak-dev] Filtering in New Account Console

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(a)abstractj.org&gt; 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(a)redhat.com&gt; > 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(a)abstractj.org&gt; 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(a)redhat.com&gt; > 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(a)abstractj.org&gt; > 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(a)redhat.com&gt; > 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(a)lists.jboss.org > >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >> > _______________________________________________ > >> >> > keycloak-dev mailing list > >> >> > keycloak-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >> > >> >> -- > >> >> > >> >> abstractj > >> > >> > >> > >> -- > >> - abstractj > > > > -- > - abstractj >