[keycloak-dev] Filtering in New Account Console
Marek Posolda
mposolda at redhat.com
Wed Oct 9 14:42:53 EDT 2019
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