[keycloak-dev] Filtering in New Account Console
Stan Silvert
ssilvert at redhat.com
Mon Oct 7 12:44:15 EDT 2019
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 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