[keycloak-dev] Filtering in New Account Console
Stian Thorgersen
sthorger at redhat.com
Fri Oct 11 04:33:54 EDT 2019
On Thu, 10 Oct 2019 at 12:41, Bruno Oliveira <bruno at abstractj.org> wrote:
> Thank you that helps. Now speaking about the UI, correct me if I'm
> wrong, but here's how it's gonna look:
>
> # Toolbar. Ref: https://i.imgur.com/o3jFi3e.png
>
> 1. Dropdown with "Name" - Remove it
> 2. Search text field: Keep it as "Filter by name".
>
I'd say so yes, not sure what else we'd search for than name
> 3. Change the dropdown menu to:
> - All apps (replacing Application-Type). I believe having
> "Application-Type" in the dropdown does not add too much value.
> - In-use
> - Offline-access
> - Third-party
> - Internal
> The suffix "only" I believe can be removed.
> 4. Checkbox with "In-use app only". Remove it because it sounds
> redundant, we will provide it into the dropdown.
>
A single drop-down with those options would work IMO. It should have some
sort of label though, not sure what that would be.
>
> # List of apps. Ref: https://i.imgur.com/qpgQFHn.png
>
> 1. At first glance, I'm gonna keep the same icon for every app. But we
> can choose icons from here:
> https://patternfly-react.surge.sh/patternfly-4/icons/Icons/. Please,
> let me know which one we want and I can do the proper changes.
>
Would need to add a config option for clients to support icon. Should
support PatternFly icon or a custom icon (not sure if that should just be
by URL or uploaded as theme resources)
> 2. Display the client id as we already do
>
Name, with fallback to client-id.
> 3. This column will display (depending on the type of app): In-use,
> Offline-access, Third-party and Internal
>
This column should be "Internal" or "Third-party"
> 4. It displays "In-use" or "Not In-use"
> - I don't have better wording for this, but we can change to anything else.
>
This column should be "In-use" "Offline-access" or just empty
> 5. Displays application base URL
>
Should it really display base URL here? Seems like details that should be
displayed in expanded view instead. Displayname/client-id (2) could link to
baseUrl if set.
>
> # Content when you click on app details. Ref:
> (https://i.imgur.com/rXvF4dx.png). Let's ignore "Google" here because
> we're not going to display identity providers.
>
> 1. Client: Display the client id
>
Name / with fallback to client-id. Label should probably be
Application/Name or something other than Client
> 2. Description of the app.
> - Today I'm not sure if we have a description field for our clients.
> Should we create this field or remove this from the UI?
>
We already have description
> 3. URL: Client Base URL
> 4. Has access to: Realm level roles assigned to scope, based on the
> Scope tab from our admin console.
>
4 Used to by scope for the client, but is now client scopes associated with
the client.
> 5. Access granted on: the date and time in which the access was
> granted to that app.
> - Maybe Doug knows, but from which field we can get this data? I'm
> looking at ClientRepresentation, but seems to be the wrong place.
> - If it's an "Internal app", omit this field.
Not sure exactly how, but this is the persisted consents that have been
granted for third-party applications. This field is not relevant to
internal applications as they don't need to be granted access.
> 6. Remove Access button: Removes the granted permission to the app and
> updates the list of apps on the current screen.
> - If it's an "Internal app", omit this button
>
Third-party yes, internal no button, offline-access button should remove
offline session
>
> Does it make sense?
>
> On Thu, Oct 10, 2019 at 5:54 AM Marek Posolda <mposolda at redhat.com> wrote:
> >
> > 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>
> 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
> >
> > +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>
> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
>
>
> --
> - abstractj
>
More information about the keycloak-dev
mailing list