[keycloak-dev] Filtering in New Account Console

Fri Oct 4 10:56:25 EDT 2019

On Fri, 4 Oct 2019, 16:41 Stan Silvert, <ssilvert at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> >> > _______________________________________________
>>> >> >> > keycloak-dev mailing list
>>> >> >> > keycloak-dev at lists.jboss.org
>>> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> >>
>>> >> >> --
>>> >> >>
>>> >> >> abstractj
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> - abstractj
>>>
>>>
>>>
>>> --
>>> - abstractj
>>>
>>
>