[keycloak-dev] Filtering in New Account Console
Stian Thorgersen
sthorger at redhat.com
Thu Oct 10 04:50:26 EDT 2019
Should probably be called Offline-access rather than Offline. As Offline
might suggest that the app itself is offline.
On Thu, 10 Oct 2019 at 10:49, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda at redhat.com> wrote:
>
>> +1 that Application Type is confusing.
>>
>> I also noticed that those screenshots use the Application Type
>> "Third-party" for the Google, Facebook and Github. Which are not really
>> clients, but identity providers.
>>
>> It seems that author of those screenshots meant to include both clients
>> and identity providers in the "Application" tab. Where the identity
>> providers are marked as "Third-party" and clients are marked as "Internal"
>> . But if I understand correctly, we don't want to include identity
>> providers in the "Application" tab?
>>
>
> Yes, we're not including identity providers in applications tab for sure.
> In this case they are just being there as example third-party apps, not
> IdPs.
>
>
>>
>> So if that's true, we may want to remove "Application Type" filter
>> entirely? Instead of it, we may have filters like "In-use app only",
>> "Offline app only", "App with consent" .
>>
>
> So we should be able to filter:
>
> * In-use only
> * Offline only
> * Third-party only
> * Internal only
>
> Exactly how that should look like, and if we can postpone the filtering to
> later is another question.
>
>
>>
>> For the last one, I am not sure if it's better to user something like
>> "App with consent" or "Third-party" . I am personally found "App with
>> consent" a bit clearer than "Third-party" . But maybe it's just because I
>> am a Keycloak developer ;)
>>
>> Marek
>>
>>
>> On 10. 10. 19 9:18, Stian Thorgersen wrote:
>>
>> While looking at the https://marvelapp.com/c90dfi0/screen/59942292 I
>> also realised that "Application Type" drowndown for Internal/Third-party is
>> a bit confusing. It's not really an application type if app is internal or
>> third-party.
>>
>> On Thu, 10 Oct 2019 at 09:17, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Okay, so I'll try to summarise this to see if we are all in agreement.
>>>
>>> Let's use https://marvelapp.com/c90dfi0/screen/59942292 as a reference
>>> as that shows how it will look like in the UI.
>>>
>>> This shows applications that are in-use and also applications that are
>>> not in-use. The latter is the one we've been discussing on how to filter
>>> all clients down time available not-in-use applications. More on that later.
>>>
>>> Further, it shows internal and third-party (consent required)
>>> applications. With an option to remove access to third party applications.
>>>
>>> It is missing applications with offline access. I suggest we add a
>>> filter "Offline app only" next to "In-use app only", and to differentiate
>>> between apps in-use and apps with offline access we could set "Offline
>>> access" where it says "In-use" for regular apps. Same as third-party apps
>>> with would have a "Remove access" button in the expanded view.
>>>
>>> To advertise applications on the account console we'd add an option to
>>> the client in admin console "Always view in account console" (not visible
>>> on bearer-only clients).
>>>
>>> Now the list of clients to include in this page would be:
>>>
>>> * All applications from current open sessions, including offline sessions
>>> * All applications with granted consents to the user (a third-party app
>>> can have a persisted consent, but not currently be in use, so this needs to
>>> be displayed)
>>> * All applications that have the "Always view in account console" option
>>> enabled
>>>
>>>
>>>
>>> On Wed, 9 Oct 2019 at 20:43, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> On 09. 10. 19 11:33, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On Tue, 8 Oct 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:
>>>>
>>>>> On 08. 10. 19 7:54, Stian Thorgersen wrote:
>>>>>
>>>>> Ok, I wasn't aware that the old console was able to list applications
>>>>> the user is not currently using. Testing it out I can see now it does
>>>>> indeed do that, but that it is broken as it lists a lot of irrelevant
>>>>> clients.
>>>>>
>>>>> What it should list is:
>>>>>
>>>>> 1. Applications currently in use - this will be any application
>>>>> registered in the session (third party apps need an option to revoke
>>>>> access, which will remove the granted consents)
>>>>> 2. Applications with offline access (these need to somehow be
>>>>> differentiated from the above and have an option to revoke access, which
>>>>> will remove the offline session)
>>>>> 3. Applications that are actual web applications and that are
>>>>> available to the user
>>>>>
>>>>> What we need to discuss is what to do in step 3. It is clear to me
>>>>> that the logic in the old console is not working correctly, so we need a
>>>>> better approach. What users need is the ability to discover applications
>>>>> they can access from the account console, that means it should be web
>>>>> applications with a baseUrl so there can be a link to open the application.
>>>>> It should not list applications just because they require consent or just
>>>>> because they can get an offline token, because that doesn't mean a user can
>>>>> actually start using them. Further, it should be possible for a admin to
>>>>> control what applications are listed there, which they can do based on what
>>>>> applications users have access to and have a baseUrl set on them.
>>>>>
>>>>> So assuming there are those two groups of clients:
>>>>>
>>>>> (a) clients, which already has consent or offline access
>>>>>
>>>>> (b) clients, which can get consent or offline access
>>>>>
>>>> Not quite. The groups are:
>>>>
>>>> (a) clients that are already in use
>>>> (b) clients that have consent
>>>> (c) clients that have offline access
>>>> (d) clients that are web applications and the user can access (i.e.
>>>> account service can link to the app and the user can actually use the app)
>>>>
>>>> clients should not be listed just because they can get consent or
>>>> offline access, those should only be listed if they fall in (d)
>>>>
>>>> Yes, there are more groups. For that particular case I wanted to
>>>> clarify, I used just 2 groups for simplification. Basically clients, which
>>>> can have stuff (consent or offline token) and clients, which already have
>>>> stuff (consent or offline token).
>>>>
>>>> I think that we're in agreement that clients from group (a) with
>>>>> already available stuff should be displayed in new account console? As
>>>>> there should be a way for the user to "Revoke" the consent or offline
>>>>> access and new access console doesn't have any other place where to revoke
>>>>> this.
>>>>>
>>>> Yes, would have to be here
>>>>
>>>>> The reason why I suggest to list also all clients from group (b) is
>>>>> some potential usability concern. For example assume you have client, which
>>>>> has active offline token, but it hasn't any roles (for example because this
>>>>> client doesn't use RBAC). Now what will happen is:
>>>>>
>>>>> - User clicks "Revoke" on client.
>>>>>
>>>>> - Client will disappear from the new account console because user
>>>>> doesn't have any roles for this client and this client doesn't have active
>>>>> offline token now.
>>>>>
>>>>> My question is, isn't it confusing from UX perspective that some
>>>>> clients will disappear from the UI when you click "Revoke" button? Just
>>>>> some clients will disappear, because clients with any permission/role
>>>>> available won't disappear.
>>>>>
>>>>> Or is it an option that clients won't disappear right-away after click
>>>>> "Revoke", but after page refresh? This would mean that after click "Revoke"
>>>>> button, UI can't send another REST request to obtain fresh list of clients
>>>>> (as that would cause client to disappear).
>>>>>
>>>> That is the expected behaviour, and would not be confusing. Try doing
>>>> it to GitHub, Google, etc. once you have removed access/consent the client
>>>> is removed from the list.
>>>>
>>>> Ok, thanks.
>>>>
>>>> That's something I wanted to clarify as it seemed to me a bit confusing
>>>> regarding user experience. But apparently, it is not.
>>>>
>>>>
>>>>> I like the idea of using (user has permission for at least one role
>>>>> with any client scope) instead of (user has one role) as front-end clients
>>>>> like SPA type apps won't use any client roles, and it also works when realm
>>>>> roles are used.
>>>>>
>>>>> Yes, I agree regarding frontend clients.
>>>>>
>>>>> Besides that, one of the original reasons for the condition (user has
>>>>> permission for at least one role with any client scope) is, that it matches
>>>>> clients with the role scope to "offline_access" role when "offline_access"
>>>>> client scope is used. Some time ago, we discussed removing "offline_access"
>>>>> role. This will makes sense now when we have client scopes and
>>>>> "offline_access" client scope.
>>>>>
>>>>> But until "offline_access" role is removed, almost all clients in the
>>>>> realm will be displayed if we use that condition. I am not sure if this is
>>>>> what we want or not (Depends on what we agree regarding the UX concern I
>>>>> had in previous paragraph).
>>>>>
>>>>>
>>>>> I'm concerned with the approach you (Marek) listed with regards to
>>>>> client scope. Iterating through every client and
>>>>> calling TokenManager.getAccess is going to be incredibly expensive, so is
>>>>> not an option, even with pagination. If you do that with pagination we'd
>>>>> need to fetch 10 clients, run TokenManager.getAccess, find 1 client with
>>>>> access, then continue until we've built enough for a single page. It has to
>>>>> be something that we can actually query directly somehow, but that is
>>>>> difficult with groups and composite roles.
>>>>>
>>>>> The performance of TokenManager.getAccess is possibly not so bad. I
>>>>> did some improvement in this part last year during work on client scopes.
>>>>> Most of the things don't need DB query as all entities (clients, client
>>>>> scopes, groups, roles, users) are cached together with their "direct" role
>>>>> memberships in the local infinispan cache. However for deployments with
>>>>> thousands of roles or clients, it could be tricky...
>>>>>
>>>> What about if there are 10K clients?
>>>>
>>>> Yep, I know. See the last sentence from the last paragraph I mentioned
>>>> :)
>>>>
>>>> Nobody yet reported any performance issue against old account console
>>>> "Applications" tab. I don't know how much people really has deployments
>>>> with thousands of roles or clients... But we need to count with the fact,
>>>> that somebody will have such use-case.
>>>>
>>>> Marek
>>>>
>>>> Thing is, that AFAIK nobody yet (surprisingly) reported any performance
>>>>> issue with the "Applications" tab in the old account console even if it
>>>>> doesn't have pagination. Maybe it is because people don't use old account
>>>>> console :) But who knows...
>>>>>
>>>>> Stan suggested to wait for feedback before doing pagination. I agree
>>>>> with that.
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On Mon, 7 Oct 2019 at 21:51, Marek Posolda <mposolda at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On 07. 10. 19 18:09, Stian Thorgersen wrote:
>>>>>>
>>>>>> Marek -
>>>>>>
>>>>>> One big difference between the new and the old console is that the
>>>>>> old console only listed applications the user was currently logged-in to
>>>>>> (basically it was listed in a session, offline or regular). The new console
>>>>>> also lists applications that are available to the user to log-in to.
>>>>>>
>>>>>> No, the old account console doesn't list only applications the user
>>>>>> is currently logged-in to. It also lists all the applications available to
>>>>>> the user.
>>>>>>
>>>>>> The old account console basically shows all the clients, which
>>>>>> matches this pseudo-condition:
>>>>>>
>>>>>> (client is NOT bearer-only && (client has consent required || (user
>>>>>> has permission for at least one role with any client scope)))
>>>>>>
>>>>>> The last sub-condition is a bit tricky, but simply said, all the
>>>>>> clients, which are allowed to retrieve offline token are listed in the old
>>>>>> console. Which are defacto almost all clients, which are not bearer-only.
>>>>>>
>>>>>> My point is, that new account console doesn't have any separate page
>>>>>> to manage offline tokens, is it correct? So the "Applications" page of new
>>>>>> account console will be still used to revoke offline tokens and consents,
>>>>>> right? In that case, the new account console should display all the
>>>>>> clients, for which user can obtain consent or offline token. And offline
>>>>>> token can by default be retrieved for almost every client in the realm,
>>>>>> which is not bearer-only. Which would mean that filtering won't help to
>>>>>> filter too much clients. Hence I guess pagination might be probably needed.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>
>>>>>> The new console should list applications within a session in the same
>>>>>> way as it is done in the old console - although not sure removing
>>>>>> bearer-only is correct. For regular sessions only apps that can do a login
>>>>>> is registered in the session, for offline sessions the client should be
>>>>>> listed regardless of its type.
>>>>>>
>>>>>> What we've been discussing here is what is the list of applications
>>>>>> available to a user, but that are not part of the session. What you are
>>>>>> suggesting doesn't make all that much sense to me in this context.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 7 Oct 2019 at 16:24, Bruno Oliveira <bruno at abstractj.org>
>>>>>> 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.
>>>>>>>
>>>>>>> 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