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

I just talked with Stian this morning and we agreed on: 1. It's mandatory that Option 1 becomes part version of the New Account Console. The current Jira was updated https://issues.jboss.org/browse/KEYCLOAK-5628 to reflect such requirement.

2 Filtering and pagination can be postponed for future releases. Jiras to follow up on this are here: - https://issues.jboss.org/browse/KEYCLOAK-11534 - https://issues.jboss.org/browse/KEYCLOAK-11677

If we are all aboard with this, I think we should move on. Otherwise, please let us know. On Fri, Oct 4, 2019 at 1:35 PM Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 04. 10. 19 16:41, Stan Silvert wrote: >> On 10/4/2019 10:16 AM, Stian Thorgersen wrote: >>> 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. >> Ideally, we should have a flag for this. I don't like the idea that we >> have to rely on the administrator to understand that a display name >> being blank in admin console conveys a certain meaning in account console. >>> 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. >> I think an approach like that would work. It would be helpful to an >> admin if there was something in the admin console that did this query >> and showed explicitly which applications a given user has access to. > BTV. Some similar filtering is already done in the old account console. > > It filtered the "bearerOnly" clients, but it didn't filter clients > without baseURL . I think that baseUrl is not mandatory field for > clients and IMO many clients don't have it configured, so not sure > whether to filter based on that... > > In addition to that you need always display clients with offline-access > and with granted consent. The old account console allowed on the > "Applications" page to see and revoke granted consents of clients and it > also allowed to see and revoke granted offline tokens. So if new account > console doesn't have any other place to view/revoke the consents and > offline tokens, it should be provided on this page. > > However if you filter to see just clients with any client role + clients > with offline-access and granted consent, it may create interesting > situations. For example imagine there is client, which doesn't have any > client roles, but it has consent granted or offline token granted. Now > user clicks the "revoke consent" (or "revoke offline token") button. > This will cause that client will disappear from the UI because it > doesn't have any client roles and it doesn't have any consent or offline > access. This seems to me like quite confusing behaviour regarding UX? > Also it will affect pagination results etc... > > With regards to this, I wonder if filtering shouldn't be the same as it > was in old account console? This was that client with consentRequired > were always included and clients with ANY role in the token for any > client scope were always included. The details are here: > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o... > > It is quite complex to compute if client has permission to see any > single role. You need to make composite roles into account etc. Hence > there is call to TokenManager.getAccess . The performance of this is not > very great, however if you have pagination with showing only 10 clients > per page, it should be just fine to use this IMO. > > In shortcut: I suggest to use exactly same filtering as done by old > account console. but add pagination support to it (which wasn't provided > by old account console). Or alternatively, if new account console has > separate page to manage offline tokens (which it maybe should have?) > then filtering can be done to display clients that: > > are NOT bearerOnly && (have consentRequired OR have any client role > available). > > By "client role available", you may still need to consider composite > roles, all possible client scopes etc, so the call to > "TokenManager.getAccess" will be still needed. > > Marek > >>> On Fri, 4 Oct 2019, 16:10 Stian Thorgersen, <sthorger(a)redhat.com >>> <mailto:sthorger@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(a)abstractj.org >>> <mailto:bruno@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(a)redhat.com <mailto:sthorger@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(a)abstractj.org <mailto:bruno@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(a)redhat.com <mailto:sthorger@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(a)abstractj.org <mailto:bruno@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(a)redhat.com <mailto:ssilvert@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(a)lists.jboss.org >>> <mailto:keycloak-dev@lists.jboss.org> >>> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > _______________________________________________ >>> >> >> > keycloak-dev mailing list >>> >> >> > keycloak-dev(a)lists.jboss.org >>> <mailto:keycloak-dev@lists.jboss.org> >>> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >>> >> >> -- >>> >> >> >>> >> >> abstractj >>> >> >>> >> >>> >> >>> >> -- >>> >> - abstractj >>> >>> >>> >>> -- >>> - abstractj >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >