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

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

2) Limit applications to those the user has access to

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)

2) Limit applications to those the user has access to

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

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

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

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

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

On 10/4/2019 8:49 AM, Bruno Oliveira 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)? I think we still need filtering and pagination. Correct me if I'm wrong but someone could still have 20 to 40 apps that they have access to? The pagination doesn't have to be that sophisticated if we are talking about a total number under 100. It could be just implemented as next and previous page like Pedro did for the Resource API.

From past experience someone always have more than we think ;)

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

I'm not sure if users would have so many clients (feedback from real use cases from the community is welcome). It seems we don't have pagination today so I'm wondering if that is a problem for people using the console? It is worth mention that this page makes much more sense for deployments where users consent access to their information. For regular enterprise use cases, where users are basically accessing internal apps to do their jobs, I don't think this page adds much value. For instance, in this case, do users need to consent/ and revoke access?

Regards. Pedro Igor On Wed, Oct 2, 2019 at 2:11 PM 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

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

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 >

On 10/7/2019 10:23 AM, Bruno Oliveira 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. I think this is a good plan. > > 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 I'm fine with this too.  We won't really know how big of an issue filtering and pagination will be until we release something that customers can start using.

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

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.

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.

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.

On Mon, 7 Oct 2019 at 21:51, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> 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 > <mailto:bruno@abstractj.org>> 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 <mailto:mposolda@redhat.com>> 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> > > >> <mailto:sthorger@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> > > >>      <mailto:bruno@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> <mailto:sthorger@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> <mailto:bruno@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> <mailto:sthorger@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> <mailto:bruno@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> <mailto:ssilvert@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> > > >>          <mailto:keycloak-dev@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> > > >>          <mailto:keycloak-dev@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 > <mailto:keycloak-dev@lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > -- > - abstractj >

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

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.

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

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

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

Adding one perhaps much much simpler approach. It is not simple/trivial to figure out what clients a user has permissions to access, but we do for sure need some way to allow sysadmins to limit what applications are listed. A much simpler option would be to introduce a simple config option on clients "Always list in account console". By default it would be OFF, but sysadmins would set it to ON to advertise common applications in the account console.

This would cover the following use-cases: * Keycloak used with a large amount of clients (lots of third-party stuff, etc.) where you only want to list the applications currently in use by the user and not use it as a way to discover other apps * Keycloak used within a company where they have a few regular apps that most users use and they want to advertise these applications It would not limit the applications listed to applications the user can actually access, but it would be good enough for now, and we can then add a follow-up to support listing only apps users can access (as a configurable option) on-demand in the future. On Wed, 9 Oct 2019 at 11:33, Stian Thorgersen <sthorger(a)redhat.com&gt; 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) >> >> 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. >> >> >> 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? >> >> 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 >>> >>> >>

Adding one perhaps much much simpler approach. It is not simple/trivial to figure out what clients a user has permissions to access, but we do for sure need some way to allow sysadmins to limit what applications are listed. A much simpler option would be to introduce a simple config option on clients "Always list in account console". By default it would be OFF, but sysadmins would set it to ON to advertise common applications in the account console. This would cover the following use-cases: * Keycloak used with a large amount of clients (lots of third-party stuff, etc.) where you only want to list the applications currently in use by the user and not use it as a way to discover other apps * Keycloak used within a company where they have a few regular apps that most users use and they want to advertise these applications It would not limit the applications listed to applications the user can actually access, but it would be good enough for now, and we can then add a follow-up to support listing only apps users can access (as a configurable option) on-demand in the future. On Wed, 9 Oct 2019 at 11:33, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> 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) 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. > > 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? 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 <mailto:mposolda@redhat.com>> 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 <mailto:bruno@abstractj.org>> 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 <mailto:mposolda@redhat.com>> >> 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> >> > >> <mailto:sthorger@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> >> > >>      <mailto:bruno@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> >> <mailto:sthorger@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> >> <mailto:bruno@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> >> <mailto:sthorger@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> >> <mailto:bruno@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> >> <mailto:ssilvert@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> >> > >>          <mailto:keycloak-dev@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> >> > >>          <mailto:keycloak-dev@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 >> <mailto:keycloak-dev@lists.jboss.org> >> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> >> >> -- >> - abstractj >> >

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

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

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

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

Should probably be called Offline-access rather than Offline. As Offline might suggest that the app itself is offline. On Thu, 10 Oct 2019 at 10:49, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> 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 <mailto:sthorger@redhat.com>> 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 <mailto:mposolda@redhat.com>> wrote: > > On 09. 10. 19 11:33, Stian Thorgersen wrote: >> >> >> On Tue, 8 Oct 2019 at 14:59, Marek Posolda >> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> >> 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 >>> <mailto:mposolda@redhat.com>> 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 >>>> <mailto:bruno@abstractj.org>> 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 >>>> <mailto:mposolda@redhat.com>> 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> >>>> > >> <mailto:sthorger@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> >>>> > >>   <mailto:bruno@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> >>>> <mailto:sthorger@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> >>>> <mailto:bruno@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> >>>> <mailto:sthorger@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> >>>> <mailto:bruno@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> >>>> <mailto:ssilvert@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> >>>> > >> >>>> <mailto:keycloak-dev@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> >>>> > >> >>>> <mailto:keycloak-dev@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 >>>> <mailto:keycloak-dev@lists.jboss.org> >>>> > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> >>>> >>>> -- >>>> - abstractj >>>> >>> >> >

Thank you that helps. Now speaking about the UI, correct me if I'm wrong, but here's how it's gonna look: # Toolbar. Ref: https://i.imgur.com/o3jFi3e.png 1. Dropdown with "Name" - Remove it 2. Search text field: Keep it as "Filter by name".

3. Change the dropdown menu to: - All apps (replacing Application-Type). I believe having "Application-Type" in the dropdown does not add too much value. - In-use - Offline-access - Third-party - Internal The suffix "only" I believe can be removed. 4. Checkbox with "In-use app only". Remove it because it sounds redundant, we will provide it into the dropdown.

# List of apps. Ref: https://i.imgur.com/qpgQFHn.png 1. At first glance, I'm gonna keep the same icon for every app. But we can choose icons from here: https://patternfly-react.surge.sh/patternfly-4/icons/Icons/. Please, let me know which one we want and I can do the proper changes.

2. Display the client id as we already do

3. This column will display (depending on the type of app): In-use, Offline-access, Third-party and Internal

4. It displays "In-use" or "Not In-use" - I don't have better wording for this, but we can change to anything else.

5. Displays application base URL

# Content when you click on app details. Ref: (https://i.imgur.com/rXvF4dx.png). Let's ignore "Google" here because we're not going to display identity providers. 1. Client: Display the client id

2. Description of the app. - Today I'm not sure if we have a description field for our clients. Should we create this field or remove this from the UI?

3. URL: Client Base URL 4. Has access to: Realm level roles assigned to scope, based on the Scope tab from our admin console.

5. Access granted on: the date and time in which the access was granted to that app. - Maybe Doug knows, but from which field we can get this data? I'm looking at ClientRepresentation, but seems to be the wrong place. - If it's an "Internal app", omit this field.

6. Remove Access button: Removes the granted permission to the app and updates the list of apps on the current screen. - If it's an "Internal app", omit this button

Does it make sense? On Thu, Oct 10, 2019 at 5:54 AM Marek Posolda <mposolda(a)redhat.com&gt; wrote: > > On 10. 10. 19 10:50, Stian Thorgersen wrote: > > Should probably be called Offline-access rather than Offline. As Offline might suggest that the app itself is offline. > > On Thu, 10 Oct 2019 at 10:49, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >> >> >> 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 > > +1 for this. And also +1 for "Offline-access" rather than "Offline" . > > Marek >> >> >> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>> > -- - abstractj

On Thu, 10 Oct 2019 at 12:41, Bruno Oliveira <bruno(a)abstractj.org <mailto:bruno@abstractj.org>> wrote: Thank you that helps. Now speaking about the UI, correct me if I'm wrong, but here's how it's gonna look: # Toolbar. Ref: https://i.imgur.com/o3jFi3e.png 1. Dropdown with "Name" - Remove it 2. Search text field: Keep it as "Filter by name". I'd say so yes, not sure what else we'd search for than name 3. Change the dropdown menu to: - All apps (replacing Application-Type). I believe having "Application-Type" in the dropdown does not add too much value. - In-use - Offline-access - Third-party - Internal The suffix "only" I believe can be removed. 4. Checkbox with "In-use app only". Remove it because it sounds redundant, we will provide it into the dropdown. A single drop-down with those options would work IMO. It should have some sort of label though, not sure what that would be. # List of apps. Ref: https://i.imgur.com/qpgQFHn.png 1. At first glance, I'm gonna keep the same icon for every app. But we can choose icons from here: https://patternfly-react.surge.sh/patternfly-4/icons/Icons/. Please, let me know which one we want and I can do the proper changes. Would need to add a config option for clients to support icon. Should support PatternFly icon or a custom icon (not sure if that should just be by URL or uploaded as theme resources)

2. Display the client id as we already do Name, with fallback to client-id. 3. This column will display (depending on the type of app): In-use, Offline-access, Third-party and Internal This column should be "Internal" or "Third-party" 4. It displays "In-use" or "Not In-use" - I don't have better wording for this, but we can change to anything else. This column should be "In-use" "Offline-access" or just empty 5. Displays application base URL Should it really display base URL here? Seems like details that should be displayed in expanded view instead. Displayname/client-id (2) could link to baseUrl if set. # Content when you click on app details. Ref: (https://i.imgur.com/rXvF4dx.png). Let's ignore "Google" here because we're not going to display identity providers. 1. Client: Display the client id Name / with fallback to client-id. Label should probably be Application/Name or something other than Client 2. Description of the app. - Today I'm not sure if we have a description field for our clients. Should we create this field or remove this from the UI? We already have description 3. URL: Client Base URL 4. Has access to: Realm level roles assigned to scope, based on the Scope tab from our admin console. 4 Used to by scope for the client, but is now client scopes associated with the client. 5. Access granted on: the date and time in which the access was granted to that app. - Maybe Doug knows, but from which field we can get this data? I'm looking at ClientRepresentation, but seems to be the wrong place. - If it's an "Internal app", omit this field. Not sure exactly how, but this is the persisted consents that have been granted for third-party applications. This field is not relevant to internal applications as they don't need to be granted access.

6. Remove Access button: Removes the granted permission to the app and updates the list of apps on the current screen. - If it's an "Internal app", omit this button Third-party yes, internal no button, offline-access button should remove offline session Does it make sense? On Thu, Oct 10, 2019 at 5:54 AM Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: > > On 10. 10. 19 10:50, Stian Thorgersen wrote: > > Should probably be called Offline-access rather than Offline. As Offline might suggest that the app itself is offline. > > On Thu, 10 Oct 2019 at 10:49, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: >> >> >> >> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> 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 > > +1 for this. And also +1 for "Offline-access" rather than "Offline" . > > Marek >> >> >> 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 <mailto:sthorger@redhat.com>> 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 <mailto:mposolda@redhat.com>> wrote: >>>>> >>>>> On 09. 10. 19 11:33, Stian Thorgersen wrote: >>>>> >>>>> >>>>> >>>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> 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 <mailto:mposolda@redhat.com>> 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 <mailto:bruno@abstractj.org>> 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 <mailto:mposolda@redhat.com>> 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> >>>>>>>> > >> <mailto:sthorger@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> >>>>>>>> > >> <mailto:bruno@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> <mailto:sthorger@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> <mailto:bruno@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> <mailto:sthorger@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> <mailto:bruno@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> <mailto:ssilvert@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> >>>>>>>> > >> <mailto:keycloak-dev@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> >>>>>>>> > >> <mailto:keycloak-dev@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 <mailto:keycloak-dev@lists.jboss.org> >>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> - abstractj >>>>>>> >>>>>>> >>>>>> >>>>> >>> > -- - abstractj

On Thu, 10 Oct 2019 at 12:41, Bruno Oliveira <bruno@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org>>> wrote: Thank you that helps. Now speaking about the UI, correct me if I'm wrong, but here's how it's gonna look: # Toolbar. Ref: https://i.imgur.com/o3jFi3e.png 1. Dropdown with "Name" - Remove it 2. Search text field: Keep it as "Filter by name". I'd say so yes, not sure what else we'd search for than name 3. Change the dropdown menu to: - All apps (replacing Application-Type). I believe having "Application-Type" in the dropdown does not add too much value. - In-use - Offline-access - Third-party - Internal The suffix "only" I believe can be removed. 4. Checkbox with "In-use app only". Remove it because it sounds redundant, we will provide it into the dropdown. A single drop-down with those options would work IMO. It should have some sort of label though, not sure what that would be. # List of apps. Ref: https://i.imgur.com/qpgQFHn.png 1. At first glance, I'm gonna keep the same icon for every app. But we can choose icons from here: https://patternfly-react.surge.sh/patternfly-4/icons/Icons/. Please, let me know which one we want and I can do the proper changes. Would need to add a config option for clients to support icon. Should support PatternFly icon or a custom icon (not sure if that should just be by URL or uploaded as theme resources)

2. Display the client id as we already do Name, with fallback to client-id. 3. This column will display (depending on the type of app): In-use, Offline-access, Third-party and Internal This column should be "Internal" or "Third-party" 4. It displays "In-use" or "Not In-use" - I don't have better wording for this, but we can change to anything else. This column should be "In-use" "Offline-access" or just empty 5. Displays application base URL Should it really display base URL here? Seems like details that should be displayed in expanded view instead. Displayname/client-id (2) could link to baseUrl if set. # Content when you click on app details. Ref: (https://i.imgur.com/rXvF4dx.png). Let's ignore "Google" here because we're not going to display identity providers. 1. Client: Display the client id Name / with fallback to client-id. Label should probably be Application/Name or something other than Client 2. Description of the app. - Today I'm not sure if we have a description field for our clients. Should we create this field or remove this from the UI? We already have description 3. URL: Client Base URL 4. Has access to: Realm level roles assigned to scope, based on the Scope tab from our admin console. 4 Used to by scope for the client, but is now client scopes associated with the client. 5. Access granted on: the date and time in which the access was granted to that app. - Maybe Doug knows, but from which field we can get this data? I'm looking at ClientRepresentation, but seems to be the wrong place. - If it's an "Internal app", omit this field. Not sure exactly how, but this is the persisted consents that have been granted for third-party applications. This field is not relevant to internal applications as they don't need to be granted access.

6. Remove Access button: Removes the granted permission to the app and updates the list of apps on the current screen. - If it's an "Internal app", omit this button Third-party yes, internal no button, offline-access button should remove offline session Does it make sense? On Thu, Oct 10, 2019 at 5:54 AM Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> wrote: > > On 10. 10. 19 10:50, Stian Thorgersen wrote: > > Should probably be called Offline-access rather than Offline. As Offline might suggest that the app itself is offline. > > On Thu, 10 Oct 2019 at 10:49, Stian Thorgersen <sthorger@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>>> wrote: >> >> >> >> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> 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 > > +1 for this. And also +1 for "Offline-access" rather than "Offline" . > > Marek >> >> >> 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@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>>> 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@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> wrote: >>>>> >>>>> On 09. 10. 19 11:33, Stian Thorgersen wrote: >>>>> >>>>> >>>>> >>>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> 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@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> 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@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org>>> 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@redhat.com<mailto:mposolda@redhat.com> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>> 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@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>> >>>>>>>> > >> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@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@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org>> >>>>>>>> > >> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@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@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@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@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org>> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@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@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com> <mailto:sthorger@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@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org>> <mailto:bruno@abstractj.org<mailto:bruno@abstractj.org> <mailto:bruno@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@redhat.com<mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com<mailto:ssilvert@redhat.com>> <mailto:ssilvert@redhat.com<mailto:ssilvert@redhat.com> <mailto:ssilvert@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>> >>>>>>>> > >> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>> >>>>>>>> > >> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> > >> >> >> > _______________________________________________ >>>>>>>> > >> >> >> > keycloak-dev mailing list >>>>>>>> > >> >> >> > keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>> >>>>>>>> > >> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> <mailto:keycloak-dev@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>> >>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> - abstractj >>>>>>> >>>>>>> >>>>>> >>>>> >>> > -- - abstractj