[keycloak-dev] Filtering in New Account Console
Marek Posolda
mposolda at redhat.com
Fri Oct 4 12:35:44 EDT 2019
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
More information about the keycloak-dev
mailing list