12:09 p.m.
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
1:10 p.m.
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> 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
10:46 a.m.
On 02. 10. 19 20:10, Pedro Igor Silva wrote:
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?
The current "applications" page in the old account management also
allows to see applications with offline token available and allow to
revoke offline tokens. So not just applications with user's consent, but
also applications with "offline tokens" .
Marek
Regards.
Pedro Igor
On Wed, Oct 2, 2019 at 2:11 PM Stan Silvert <ssilvert(a)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
> 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
4:02 a.m.
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)
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).
On Wed, 2 Oct 2019 at 19:11, Stan Silvert <ssilvert(a)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
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:54 a.m.
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.
>
> 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> 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
6:59 a.m.
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> 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> 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
7:31 a.m.
#1 is the only thing that makes sense to me. Agree that it would be a
nice value add.
We already have a different UI for active sessions in Device Activity,
so #2 is kind of redundant.
Stan
On 10/4/2019 7:59 AM, Stian Thorgersen 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
7:49 a.m.
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> 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> 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> 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
8:24 a.m.
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> 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>
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> 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>
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
8:41 a.m.
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> 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> 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> 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> 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>
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
9:10 a.m.
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> 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>
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> 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>
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>
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>
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
9:16 a.m.
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.
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.
On Fri, 4 Oct 2019, 16:10 Stian Thorgersen, <sthorger(a)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> 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>
> 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> 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>
> 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>
> 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>
> 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
>
9:41 a.m.
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.
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
9:56 a.m.
On Fri, 4 Oct 2019, 16:41 Stan Silvert, <ssilvert(a)redhat.com> 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.
Without display name it would have to show client-id which would not be
very nice, but would be visible at least to admins. So perhaps just leave
this check.
A flag 'display in account console' may be a nice idea though.
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.
Yea, but that sounds more like a lower priority thing to me.
On Fri, 4 Oct 2019, 16:10 Stian Thorgersen, <sthorger(a)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> 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>
>> 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>
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>
>> 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>
>> 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>
>> 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
>>
>
11:35 a.m.
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
9:23 a.m.
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> 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
11:09 a.m.
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.
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> 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> 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
2:50 p.m.
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
12:54 a.m.
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> 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> 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> 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
>
7:59 a.m.
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
<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
>
10:53 a.m.
Adding Doug directly to the thread. He is the one implementing this.
On 10/8/2019 8:59 AM, Marek Posolda 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
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
> <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
>>
>
4:33 a.m.
On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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> 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>
>> 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
>>
>
>
4:38 a.m.
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> wrote:
On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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> 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>
>>> 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
>>>
>>
>>
>
12:37 p.m.
Based on what you mentioned I believe the UI
(https://marvelapp.com/c90dfi0/screen/59942289) will change, right? So
If I understood correctly the applications endpoint should return
clients based on the follow criteria (just copy and paste from your
previous e-mail):
(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)
On Wed, Oct 9, 2019 at 6:38 AM Stian Thorgersen <sthorger(a)redhat.com> wrote:
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.
I'm a bit lost about this. In which part of the interface you think we
should add this? Maybe we could settle about implementation details
and make sure requirements reflected on Jiras.
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> wrote:
>
>
>
> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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>
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>
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
1:52 p.m.
+1
I was thinking a bit about something similar too. One thing is the
performance of figuring the roles. Another thing is that it is possible
that there are many clients, which don't use RBAC at all. Especially now
when we have authorization services. The fact that client doesn't have
role scope mapping for any roles doesn't mean much. Nothing prevents
user to authenticate to such client even if there won't be any roles in
the token.
Marek
On 09. 10. 19 11:38, Stian Thorgersen wrote:
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
>>
>
1:42 p.m.
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
>>
>
2:17 a.m.
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> wrote:
On 09. 10. 19 11:33, Stian Thorgersen wrote:
On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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> 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>
>>> 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
>>>
>>
>>
>
2:18 a.m.
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> 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> wrote:
> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>
>
>
> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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>
>>> 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>
>>>> 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
>>>>
>>>
>>>
>>
>
3:17 a.m.
+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
<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
>>>
>>
>
3:49 a.m.
On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)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>
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> wrote:
>
>> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>>
>>
>>
>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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>
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>
>>>> 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>
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>
3:50 a.m.
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> wrote:
On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)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>
> 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> wrote:
>>
>>> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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>
>>>> 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>
>>>>> 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>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
3:54 a.m.
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
>>>>
>>>
>>
>
5:40 a.m.
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> 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> wrote:
>
>
>
> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)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>
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>
wrote:
>>>>
>>>> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda(a)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> 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> 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> 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
3:33 a.m.
On Thu, 10 Oct 2019 at 12:41, Bruno Oliveira <bruno(a)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> 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>
wrote:
>>
>>
>>
>> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda(a)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>
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>
wrote:
>>>>>
>>>>> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda
<mposolda(a)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>
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>
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>
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
8:27 a.m.
On 11. 10. 19 10:33, Stian Thorgersen wrote:
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)
The OIDC dynamic client registration has
support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date
and last access date.
Marek
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
8:34 a.m.
Hi everybody,
First of all sorry for jumping on this so late, I fell 1600 mails behind and I am still
catching up.
We are want to use Keycloak to give GDPR-compliant consents. In a nutshell, the user must
be able to decide which data is used for which purpose. If the purposes are not closely
related, I must be able to pick the purposes I consent to individually.
E.g. if I am asked whether my email address (data) might be used to send me a newsletter
or to send me bills, I should be able to say yes to the bills and no to the newsletter.
GDPR does not say a user must be able to decide on the data, it says you should in general
only process necessary data but not more.
Assuming a client accesses data at a REST API, the data a client gets access to is
associated with the API roles the client gets delegated from the user. The purpose would
be a client scope as defined by the client, since it’s the client that's doing
something with the data it gets access to. This also means a client onboarding process
would probably look different from today, as the client developer would have to define its
scope and pick the API roles he wants to associate with the client scopes.
In any case, it must be possible to select individual scopes granted to the client on the
OAuth consent page and it would be useful if individual scopes could also be
granted/revoked on the applications page.
And in the latter case, wouldn't it be possible to treat offline_access just like any
other scope that can be revoked individually? Or is there some special processing
necessary to revoke offline tokens?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> Im
Auftrag von Marek Posolda
Gesendet: Freitag, 11. Oktober 2019 15:27
An: stian(a)redhat.com; Bruno Oliveira <bruno(a)abstractj.org>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Filtering in New Account Console
On 11. 10. 19 10:33, Stian Thorgersen wrote:
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)
The OIDC dynamic client registration has
support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date and last access
date.
Marek
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:14 a.m.
I'm not sure I see how that's related to this thread, so would probably be
better to start a new thread around this topic?
On Fri, 1 Nov 2019 at 14:34, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi everybody,
First of all sorry for jumping on this so late, I fell 1600 mails behind
and I am still catching up.
We are want to use Keycloak to give GDPR-compliant consents. In a
nutshell, the user must be able to decide which data is used for which
purpose. If the purposes are not closely related, I must be able to pick
the purposes I consent to individually.
E.g. if I am asked whether my email address (data) might be used to send
me a newsletter or to send me bills, I should be able to say yes to the
bills and no to the newsletter. GDPR does not say a user must be able to
decide on the data, it says you should in general only process necessary
data but not more.
Assuming a client accesses data at a REST API, the data a client gets
access to is associated with the API roles the client gets delegated from
the user. The purpose would be a client scope as defined by the client,
since it’s the client that's doing something with the data it gets access
to. This also means a client onboarding process would probably look
different from today, as the client developer would have to define its
scope and pick the API roles he wants to associate with the client scopes.
In any case, it must be possible to select individual scopes granted to
the client on the OAuth consent page and it would be useful if individual
scopes could also be granted/revoked on the applications page.
And in the latter case, wouldn't it be possible to treat offline_access
just like any other scope that can be revoked individually? Or is there
some special processing necessary to revoke offline tokens?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30
726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> Im Auftrag von Marek Posolda
Gesendet: Freitag, 11. Oktober 2019 15:27
An: stian(a)redhat.com; Bruno Oliveira <bruno(a)abstractj.org>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Filtering in New Account Console
On 11. 10. 19 10:33, Stian Thorgersen wrote:
>
>
> 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)
The OIDC dynamic client registration has support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
>
> 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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date and
last access date.
Marek
> 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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:10 a.m.
Admitted it was a lengthy introduction to raise the question whether offline_access could
be handled as just another scope instead of a special case when filtering – which was the
agreed proposal when the discussion ended as far as I understood.
But I will start a new thread about the GDRP consent topic as there are more issues
involved in this topic.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
Von: Stian Thorgersen <sthorger(a)redhat.com>
Gesendet: Freitag, 1. November 2019 15:14
An: Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster(a)bosch-si.com>
Cc: Marek Posolda <mposolda(a)redhat.com>; Bruno Oliveira <bruno(a)abstractj.org>;
keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Filtering in New Account Console
I'm not sure I see how that's related to this thread, so would probably be better
to start a new thread around this topic?
On Fri, 1 Nov 2019 at 14:34, Schuster Sebastian (INST-CSS/BSV-OS2)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
Hi everybody,
First of all sorry for jumping on this so late, I fell 1600 mails behind and I am still
catching up.
We are want to use Keycloak to give GDPR-compliant consents. In a nutshell, the user must
be able to decide which data is used for which purpose. If the purposes are not closely
related, I must be able to pick the purposes I consent to individually.
E.g. if I am asked whether my email address (data) might be used to send me a newsletter
or to send me bills, I should be able to say yes to the bills and no to the newsletter.
GDPR does not say a user must be able to decide on the data, it says you should in general
only process necessary data but not more.
Assuming a client accesses data at a REST API, the data a client gets access to is
associated with the API roles the client gets delegated from the user. The purpose would
be a client scope as defined by the client, since it’s the client that's doing
something with the data it gets access to. This also means a client onboarding process
would probably look different from today, as the client developer would have to define its
scope and pick the API roles he wants to associate with the client scopes.
In any case, it must be possible to select individual scopes granted to the client on the
OAuth consent page and it would be useful if individual scopes could also be
granted/revoked on the applications page.
And in the latter case, wouldn't it be possible to treat offline_access just like any
other scope that can be revoked individually? Or is there some special processing
necessary to revoke offline tokens?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von:
keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>
<keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>>
Im Auftrag von Marek Posolda
Gesendet: Freitag, 11. Oktober 2019 15:27
An: stian@redhat.com<mailto:stian@redhat.com>; Bruno Oliveira
<bruno@abstractj.org<mailto:bruno@abstractj.org>>
Cc: keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Betreff: Re: [keycloak-dev] Filtering in New Account Console
On 11. 10. 19 10:33, Stian Thorgersen wrote:
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)
The OIDC dynamic client registration has support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date and last access
date.
Marek
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:36 a.m.
Problem is that offline_access has special meaning, resulting in an offline
session being created, not just some extra claims in the token. To be
honest I never understood why it is a scope in the first place in the specs.
Within the application list of the new account console we should list
applications that have offline sessions, not those that could have.
On Fri, 1 Nov 2019 at 16:10, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Admitted it was a lengthy introduction to raise the question whether
offline_access could be handled as just another scope instead of a special
case when filtering – which was the agreed proposal when the discussion
ended as far as I understood.
But I will start a new thread about the GDRP consent topic as there are
more issues involved in this topic.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
*Dr.-Ing. **Sebastian Schuster*
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY
| www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30
726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
*Von:* Stian Thorgersen <sthorger(a)redhat.com>
*Gesendet:* Freitag, 1. November 2019 15:14
*An:* Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com>
*Cc:* Marek Posolda <mposolda(a)redhat.com>; Bruno Oliveira <
bruno(a)abstractj.org>; keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Betreff:* Re: [keycloak-dev] Filtering in New Account Console
I'm not sure I see how that's related to this thread, so would probably be
better to start a new thread around this topic?
On Fri, 1 Nov 2019 at 14:34, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi everybody,
First of all sorry for jumping on this so late, I fell 1600 mails behind
and I am still catching up.
We are want to use Keycloak to give GDPR-compliant consents. In a
nutshell, the user must be able to decide which data is used for which
purpose. If the purposes are not closely related, I must be able to pick
the purposes I consent to individually.
E.g. if I am asked whether my email address (data) might be used to send
me a newsletter or to send me bills, I should be able to say yes to the
bills and no to the newsletter. GDPR does not say a user must be able to
decide on the data, it says you should in general only process necessary
data but not more.
Assuming a client accesses data at a REST API, the data a client gets
access to is associated with the API roles the client gets delegated from
the user. The purpose would be a client scope as defined by the client,
since it’s the client that's doing something with the data it gets access
to. This also means a client onboarding process would probably look
different from today, as the client developer would have to define its
scope and pick the API roles he wants to associate with the client scopes.
In any case, it must be possible to select individual scopes granted to
the client on the OAuth consent page and it would be useful if individual
scopes could also be granted/revoked on the applications page.
And in the latter case, wouldn't it be possible to treat offline_access
just like any other scope that can be revoked individually? Or is there
some special processing necessary to revoke offline tokens?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30
726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> Im Auftrag von Marek Posolda
Gesendet: Freitag, 11. Oktober 2019 15:27
An: stian(a)redhat.com; Bruno Oliveira <bruno(a)abstractj.org>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Filtering in New Account Console
On 11. 10. 19 10:33, Stian Thorgersen wrote:
>
>
> 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)
The OIDC dynamic client registration has support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
>
> 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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date and
last access date.
Marek
> 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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:44 a.m.
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> 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
>
2:56 p.m.
On 07. 10. 19 18:44, Stan Silvert wrote:
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.
Yes, it may help to wait for the feedback. The old account console
didn't have pagination and I can't recall any issue. However not sure if
the reason is, that people just didn't use the "Applications" page in
the old account console :)
However if we expect that people will use "Applications" page in new
account console more often, pagination will be requested IMO. Just a
guess...
Marek
> 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>
> 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
>>
>
9:31 a.m.
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.
On Fri, Oct 4, 2019 at 8:59 AM Stian Thorgersen <sthorger(a)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> 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> 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
9:53 a.m.
On Fri, 4 Oct 2019, 16:31 Stan Silvert, <ssilvert(a)redhat.com> wrote:
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>
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>
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>
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
1878
days inactive
1912
days old
42 comments
6 participants
participants (6)
-
Bruno Oliveira -
Marek Posolda -
Pedro Igor Silva -
Schuster Sebastian (INST-CSS/BSV-OS2) -
Stan Silvert -
Stian Thorgersen