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

On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > +1 that Application Type is confusing. > > I also noticed that those screenshots use the Application Type > "Third-party" for the Google, Facebook and Github. Which are not really > clients, but identity providers. > > It seems that author of those screenshots meant to include both clients > and identity providers in the "Application" tab. Where the identity > providers are marked as "Third-party" and clients are marked as "Internal" > . But if I understand correctly, we don't want to include identity > providers in the "Application" tab? > Yes, we're not including identity providers in applications tab for sure. In this case they are just being there as example third-party apps, not IdPs. > > So if that's true, we may want to remove "Application Type" filter > entirely? Instead of it, we may have filters like "In-use app only", > "Offline app only", "App with consent" . > So we should be able to filter: * In-use only * Offline only * Third-party only * Internal only Exactly how that should look like, and if we can postpone the filtering to later is another question. > > For the last one, I am not sure if it's better to user something like > "App with consent" or "Third-party" . I am personally found "App with > consent" a bit clearer than "Third-party" . But maybe it's just because I > am a Keycloak developer ;) > > Marek > > > On 10. 10. 19 9:18, Stian Thorgersen wrote: > > While looking at the https://marvelapp.com/c90dfi0/screen/59942292 I > also realised that "Application Type" drowndown for Internal/Third-party is > a bit confusing. It's not really an application type if app is internal or > third-party. > > On Thu, 10 Oct 2019 at 09:17, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> Okay, so I'll try to summarise this to see if we are all in agreement. >> >> Let's use https://marvelapp.com/c90dfi0/screen/59942292 as a reference >> as that shows how it will look like in the UI. >> >> This shows applications that are in-use and also applications that are >> not in-use. The latter is the one we've been discussing on how to filter >> all clients down time available not-in-use applications. More on that later. >> >> Further, it shows internal and third-party (consent required) >> applications. With an option to remove access to third party applications. >> >> It is missing applications with offline access. I suggest we add a >> filter "Offline app only" next to "In-use app only", and to differentiate >> between apps in-use and apps with offline access we could set "Offline >> access" where it says "In-use" for regular apps. Same as third-party apps >> with would have a "Remove access" button in the expanded view. >> >> To advertise applications on the account console we'd add an option to >> the client in admin console "Always view in account console" (not visible >> on bearer-only clients). >> >> Now the list of clients to include in this page would be: >> >> * All applications from current open sessions, including offline sessions >> * All applications with granted consents to the user (a third-party app >> can have a persisted consent, but not currently be in use, so this needs to >> be displayed) >> * All applications that have the "Always view in account console" option >> enabled >> >> >> >> On Wed, 9 Oct 2019 at 20:43, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> >>> On 09. 10. 19 11:33, Stian Thorgersen wrote: >>> >>> >>> >>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>> >>>> On 08. 10. 19 7:54, Stian Thorgersen wrote: >>>> >>>> Ok, I wasn't aware that the old console was able to list applications >>>> the user is not currently using. Testing it out I can see now it does >>>> indeed do that, but that it is broken as it lists a lot of irrelevant >>>> clients. >>>> >>>> What it should list is: >>>> >>>> 1. Applications currently in use - this will be any application >>>> registered in the session (third party apps need an option to revoke >>>> access, which will remove the granted consents) >>>> 2. Applications with offline access (these need to somehow be >>>> differentiated from the above and have an option to revoke access, which >>>> will remove the offline session) >>>> 3. Applications that are actual web applications and that are >>>> available to the user >>>> >>>> What we need to discuss is what to do in step 3. It is clear to me >>>> that the logic in the old console is not working correctly, so we need a >>>> better approach. What users need is the ability to discover applications >>>> they can access from the account console, that means it should be web >>>> applications with a baseUrl so there can be a link to open the application. >>>> It should not list applications just because they require consent or just >>>> because they can get an offline token, because that doesn't mean a user can >>>> actually start using them. Further, it should be possible for a admin to >>>> control what applications are listed there, which they can do based on what >>>> applications users have access to and have a baseUrl set on them. >>>> >>>> So assuming there are those two groups of clients: >>>> >>>> (a) clients, which already has consent or offline access >>>> >>>> (b) clients, which can get consent or offline access >>>> >>> Not quite. The groups are: >>> >>> (a) clients that are already in use >>> (b) clients that have consent >>> (c) clients that have offline access >>> (d) clients that are web applications and the user can access (i.e. >>> account service can link to the app and the user can actually use the app) >>> >>> clients should not be listed just because they can get consent or >>> offline access, those should only be listed if they fall in (d) >>> >>> Yes, there are more groups. For that particular case I wanted to >>> clarify, I used just 2 groups for simplification. Basically clients, which >>> can have stuff (consent or offline token) and clients, which already have >>> stuff (consent or offline token). >>> >>> I think that we're in agreement that clients from group (a) with >>>> already available stuff should be displayed in new account console? As >>>> there should be a way for the user to "Revoke" the consent or offline >>>> access and new access console doesn't have any other place where to revoke >>>> this. >>>> >>> Yes, would have to be here >>> >>>> The reason why I suggest to list also all clients from group (b) is >>>> some potential usability concern. For example assume you have client, which >>>> has active offline token, but it hasn't any roles (for example because this >>>> client doesn't use RBAC). Now what will happen is: >>>> >>>> - User clicks "Revoke" on client. >>>> >>>> - Client will disappear from the new account console because user >>>> doesn't have any roles for this client and this client doesn't have active >>>> offline token now. >>>> >>>> My question is, isn't it confusing from UX perspective that some >>>> clients will disappear from the UI when you click "Revoke" button? Just >>>> some clients will disappear, because clients with any permission/role >>>> available won't disappear. >>>> >>>> Or is it an option that clients won't disappear right-away after click >>>> "Revoke", but after page refresh? This would mean that after click "Revoke" >>>> button, UI can't send another REST request to obtain fresh list of clients >>>> (as that would cause client to disappear). >>>> >>> That is the expected behaviour, and would not be confusing. Try doing >>> it to GitHub, Google, etc. once you have removed access/consent the client >>> is removed from the list. >>> >>> Ok, thanks. >>> >>> That's something I wanted to clarify as it seemed to me a bit confusing >>> regarding user experience. But apparently, it is not. >>> >>> >>>> I like the idea of using (user has permission for at least one role >>>> with any client scope) instead of (user has one role) as front-end clients >>>> like SPA type apps won't use any client roles, and it also works when realm >>>> roles are used. >>>> >>>> Yes, I agree regarding frontend clients. >>>> >>>> Besides that, one of the original reasons for the condition (user has >>>> permission for at least one role with any client scope) is, that it matches >>>> clients with the role scope to "offline_access" role when "offline_access" >>>> client scope is used. Some time ago, we discussed removing "offline_access" >>>> role. This will makes sense now when we have client scopes and >>>> "offline_access" client scope. >>>> >>>> But until "offline_access" role is removed, almost all clients in the >>>> realm will be displayed if we use that condition. I am not sure if this is >>>> what we want or not (Depends on what we agree regarding the UX concern I >>>> had in previous paragraph). >>>> >>>> >>>> I'm concerned with the approach you (Marek) listed with regards to >>>> client scope. Iterating through every client and >>>> calling TokenManager.getAccess is going to be incredibly expensive, so is >>>> not an option, even with pagination. If you do that with pagination we'd >>>> need to fetch 10 clients, run TokenManager.getAccess, find 1 client with >>>> access, then continue until we've built enough for a single page. It has to >>>> be something that we can actually query directly somehow, but that is >>>> difficult with groups and composite roles. >>>> >>>> The performance of TokenManager.getAccess is possibly not so bad. I >>>> did some improvement in this part last year during work on client scopes. >>>> Most of the things don't need DB query as all entities (clients, client >>>> scopes, groups, roles, users) are cached together with their "direct" role >>>> memberships in the local infinispan cache. However for deployments with >>>> thousands of roles or clients, it could be tricky... >>>> >>> What about if there are 10K clients? >>> >>> Yep, I know. See the last sentence from the last paragraph I mentioned >>> :) >>> >>> Nobody yet reported any performance issue against old account console >>> "Applications" tab. I don't know how much people really has deployments >>> with thousands of roles or clients... But we need to count with the fact, >>> that somebody will have such use-case. >>> >>> Marek >>> >>> Thing is, that AFAIK nobody yet (surprisingly) reported any performance >>>> issue with the "Applications" tab in the old account console even if it >>>> doesn't have pagination. Maybe it is because people don't use old account >>>> console :) But who knows... >>>> >>>> Stan suggested to wait for feedback before doing pagination. I agree >>>> with that. >>>> >>>> Marek >>>> >>>> >>>> On Mon, 7 Oct 2019 at 21:51, Marek Posolda <mposolda(a)redhat.com&gt; >>>> wrote: >>>> >>>>> On 07. 10. 19 18:09, Stian Thorgersen wrote: >>>>> >>>>> Marek - >>>>> >>>>> One big difference between the new and the old console is that the >>>>> old console only listed applications the user was currently logged-in to >>>>> (basically it was listed in a session, offline or regular). The new console >>>>> also lists applications that are available to the user to log-in to. >>>>> >>>>> No, the old account console doesn't list only applications the user >>>>> is currently logged-in to. It also lists all the applications available to >>>>> the user. >>>>> >>>>> The old account console basically shows all the clients, which >>>>> matches this pseudo-condition: >>>>> >>>>> (client is NOT bearer-only && (client has consent required || (user >>>>> has permission for at least one role with any client scope))) >>>>> >>>>> The last sub-condition is a bit tricky, but simply said, all the >>>>> clients, which are allowed to retrieve offline token are listed in the old >>>>> console. Which are defacto almost all clients, which are not bearer-only. >>>>> >>>>> My point is, that new account console doesn't have any separate page >>>>> to manage offline tokens, is it correct? So the "Applications" page of new >>>>> account console will be still used to revoke offline tokens and consents, >>>>> right? In that case, the new account console should display all the >>>>> clients, for which user can obtain consent or offline token. And offline >>>>> token can by default be retrieved for almost every client in the realm, >>>>> which is not bearer-only. Which would mean that filtering won't help to >>>>> filter too much clients. Hence I guess pagination might be probably needed. >>>>> >>>>> Marek >>>>> >>>>> >>>>> The new console should list applications within a session in the same >>>>> way as it is done in the old console - although not sure removing >>>>> bearer-only is correct. For regular sessions only apps that can do a login >>>>> is registered in the session, for offline sessions the client should be >>>>> listed regardless of its type. >>>>> >>>>> What we've been discussing here is what is the list of applications >>>>> available to a user, but that are not part of the session. What you are >>>>> suggesting doesn't make all that much sense to me in this context. >>>>> >>>>> >>>>> >>>>> On Mon, 7 Oct 2019 at 16:24, Bruno Oliveira <bruno(a)abstractj.org&gt; >>>>> wrote: >>>>> >>>>>> 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 >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> -- >>>>>> - abstractj >>>>>> >>>>> >>>>> >>>> >>> >