[keycloak-dev] Filtering in New Account Console
Marek Posolda
mposolda at redhat.com
Mon Oct 7 15:56:38 EDT 2019
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 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
>>>
>>
>
More information about the keycloak-dev
mailing list