[keycloak-dev] Filtering in New Account Console
Marek Posolda
mposolda at redhat.com
Thu Oct 10 04:54:42 EDT 2019
On 10. 10. 19 10:50, Stian Thorgersen wrote:
> 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
> <mailto:sthorger at redhat.com>> wrote:
>
>
>
> On Thu, 10 Oct 2019 at 10:17, Marek Posolda <mposolda at redhat.com
> <mailto: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
>
+1 for this. And also +1 for "Offline-access" rather than "Offline" .
Marek
>
> 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 <mailto: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 <mailto: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 <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>> <mailto: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>
>>>>> > >> <mailto: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>
>>>>> > >> <mailto: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>
>>>>> <mailto: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>
>>>>> <mailto: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>
>>>>> <mailto: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>
>>>>> <mailto: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>
>>>>> <mailto: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>
>>>>> > >>
>>>>> <mailto: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>
>>>>> > >>
>>>>> <mailto: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
>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>> > >
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> - abstractj
>>>>>
>>>>
>>>
>>
>
More information about the keycloak-dev
mailing list