[keycloak-dev] Filtering in New Account Console
Marek Posolda
mposolda at redhat.com
Fri Oct 11 09:27:13 EDT 2019
On 11. 10. 19 10:33, Stian Thorgersen wrote:
>
>
> On Thu, 10 Oct 2019 at 12:41, Bruno Oliveira <bruno at abstractj.org
> <mailto: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)
The OIDC dynamic client registration has support for "logo_uri" :
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
>
> 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.
List<UserConsentModel> consents =
session.users().getConsents(realmModel, userId);
Each UserConsentModel contains info about client, consent created date
and last access date.
Marek
> 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
> <mailto: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 <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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
>
>
> --
> - abstractj
>
More information about the keycloak-dev
mailing list