My preference is a new client for the new account console, with the current
client being used for the old server-side account console and roles. It is
safer and has less potential of having any side-effects now and in the
future.
On Mon, 18 Nov 2019 at 09:51, Stian Thorgersen <sthorger(a)redhat.com> wrote:
The only place that would need to change is the client used in
keycloak.js
by the new account console, so should be a one-line change. The other
things should stay as is since those are related to the roles.
It would probably work to change to public for now though. This will need
to change in the future regardless as we should remove keycloak.js from
account and admin consoles, since they are colocated with the REST APIs
they should use cookies, not tokens in-mem.
On Sun, 17 Nov 2019 at 21:12, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 15. 11. 19 21:10, Stan Silvert wrote:
> > On 11/15/2019 12:15 PM, Stan Silvert wrote:
> >> On 11/15/2019 9:05 AM, Stian Thorgersen wrote:
> >>> The account console should be a confidential client as it is there for
> >>> the old account console.
> >>>
> >>> Instead you should create a new client for the new account console.
> >> Sigh. That's definitely not the answer I was hoping for.
> > So this is looking like a very big change. There is code all over the
> > place assuming that the client id is "account". I really don't
want to
> > hack up our code everywhere to make it point to a different client
> > definition every time the Theme is set to "keycloak-preview".
It's more
> > than just changing the return value of
> > Constants.ACCOUNT_MANAGEMENT_CLIENT_ID.
> >
> > Additionally, any changes I make would need to revert back once new
> > account console becomes standard. So changes that only support tech
> > preview don't make a lot of sense.
> >
> > I see two less-invasive solutions:
> > 1) Allow the old account console to be a public client.
> > 2) Document that "tech preview" users should go to Client ->
account.
> > Then change the Access Type to "public".
>
> The old account console is using a bit different flow than normal OIDC
> confidential clients. It relies on the fact that it is deployed on same
> server as Keycloak and it just uses the Keycloak cookies like
> KEYCLOAK_IDENTITY cookie for the authentication. AFAIK it doesn't use
> any OIDC backchannel requests, which require client authentication.
>
> In other words, I think that changing old account console to public
> client shouldn't break anything. So IMO solution 1 will just work.
>
> However I am not 100% sure. It will be good to run the testsuite after
> changing the "account" client to public and do some more checks of
> sources. But AFAIK I can't recall any reason why it won't work.
>
> Marek
>
>
> >
> >>> On Fri, 15 Nov 2019 at 14:03, Stan Silvert <ssilvert(a)redhat.com
> >>> <mailto:ssilvert@redhat.com>> wrote:
> >>>
> >>> On 11/7/2019 7:46 AM, Stian Thorgersen wrote:
> >>> > It might be there from the early days when we didn't
have
> public
> >>> clients.
> >>> > I'd probably just keep it in case someone is using it
with a
> >>> confidential
> >>> > client as removing it would break it for them. Although
> strictly
> >>> speaking
> >>> > you shouldn't use a confidential client with a
client-side
> app.
> >>> There is something else left over from when we didn't have
> public
> >>> clients. The account console is still a confidential client.
> >>>
> >>> With this latest change in the javascript adapter, the new
> account
> >>> console is broken. (Both old and new account console use the
> same
> >>> client definition)
> >>>
> >>> Does anyone have an issue with changing the (old and new)
> account
> >>> console to a public client?
> >>>
> >>> >
> >>> > On Thu, 7 Nov 2019 at 07:42, Michal Hajas
<mhajas(a)redhat.com
> >>> <mailto:mhajas@redhat.com>> wrote:
> >>> >
> >>> >> Hello,
> >>> >>
> >>> >> in Javascript adapter we have a possibility to configure
a
> >>> client secret
> >>> >> [1] in order to use Basic authorization for requests for
> token
> >>> endpoint
> >>> >> [2]. I haven't found any information in docs about it
and I
> don't
> >>> >> understand why we have it there as public clients
don't have
> >>> secrets. Is
> >>> >> this useful in some scenarios or we should remove it?
> >>> >>
> >>> >> Michal
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> >>>
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >>> >> &
> >>> >>
> >>> <
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >
> >>> >>
> >>> >>
> >>>
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >>> >>
> >>> >> [2]
> >>> >>
> >>> >>
> >>>
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >>> >> &
> >>> >>
> >>> <
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >
> >>> >>
> >>> >>
> >>>
>
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/mai...
> >>> >> _______________________________________________
> >>> >> keycloak-dev mailing list
> >>> >> keycloak-dev(a)lists.jboss.org <mailto:
> keycloak-dev(a)lists.jboss.org>
> >>> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >>
> >>> > _______________________________________________
> >>> > keycloak-dev mailing list
> >>> > keycloak-dev(a)lists.jboss.org <mailto:
> keycloak-dev(a)lists.jboss.org>
> >>> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev