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

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