[keycloak-dev] Filtering in New Account Console
Stan Silvert
ssilvert at redhat.com
Fri Oct 4 08:31:21 EDT 2019
#1 is the only thing that makes sense to me. Agree that it would be a
nice value add.
We already have a different UI for active sessions in Device Activity,
so #2 is kind of redundant.
Stan
On 10/4/2019 7:59 AM, Stian Thorgersen 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
>
More information about the keycloak-dev
mailing list