[keycloak-dev] Filtering in New Account Console
Bruno Oliveira
bruno at abstractj.org
Mon Oct 7 10:23:25 EDT 2019
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 at 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/org/keycloak/forms/account/freemarker/model/ApplicationsBean.java#L67
>
> 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 at redhat.com
> >> <mailto: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
> >> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
> >> <mailto:keycloak-dev at lists.jboss.org>
> >> >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> >> > _______________________________________________
> >> >> >> > keycloak-dev mailing list
> >> >> >> > keycloak-dev at lists.jboss.org
> >> <mailto:keycloak-dev at lists.jboss.org>
> >> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> abstractj
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> - abstractj
> >>
> >>
> >>
> >> --
> >> - abstractj
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
--
- abstractj
More information about the keycloak-dev
mailing list