[keycloak-dev] Credentials in javascript adapter
Stan Silvert
ssilvert at redhat.com
Mon Nov 18 08:55:12 EST 2019
On 11/18/2019 8:31 AM, Václav Muzikář wrote:
> +1 on making a special new client just for the new account console
> ("account2")?
> I don't see any need to select client name based on theme name.
The way it works right now is that all Keycloak code assumes that the
account console is named "account". Until recent changes, all you had
to do to get the new account console was to change the theme. It still
used the "account" client.
If we have a new "account2" client then all Keycloak code would need to
know that when you change the theme to "keycloak-preview" it needs to
use "account2" instead of "account". I tried to see what would happen
if I just change the value of Constants.ACCOUNT_MANAGEMENT_CLIENT_ID to
"account2". It didn't work. There is just too much code out there that
assumes it will be called "account" and that the account console is
served from /auth/realms/master/account/.
Again, the least invasive changes are:
1) Allow the old account console to be a public client.
2) Document that "tech preview" users should go to Client -> account.
Then manually change the Access Type to "public".
> Why couldn't the new account console use e.g. "account2" client even
> when it replaced the old console?
>
> In any case, I see this as a bit unnecessary overhead right now when
> we're trying to focus on the tech preview.
>
> On Mon, Nov 18, 2019 at 2:26 PM Stan Silvert <ssilvert at redhat.com
> <mailto:ssilvert at redhat.com>> wrote:
>
> On 11/18/2019 7:04 AM, Stian Thorgersen wrote:
> > 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.
> I do understand that concern. But it's a big hairy mess to allow
> conditional selection of the client based on selecting
> "keycloak-preview" theme. So just changing the client to "public"
> seems
> like a less risky proposition.
>
> Perhaps you can expand on what you said earlier when you said,
> "Although
> strictly speaking you shouldn't use a confidential client with a
> client-side app."?
>
> Also remember, that we still have option #2, which requires only a
> documentation note. That is:
> 2) Document that "tech preview" users should go to Client -> account.
> Then change the Access Type to "public".
>
> If you want, I can implement option #1 and just do a PR with the
> change
> of "account" client to "public". Then we can see if that breaks
> anything. That would at least tell us a little more. Then we can
> make
> a final decision on what to do.
>
> But I don't want to wait very long for a decision. We need to get
> this
> nailed down so we can finish new account console in time for tech
> preview.
>
> >
> > On Mon, 18 Nov 2019 at 09:51, Stian Thorgersen
> <sthorger at redhat.com <mailto:sthorger at redhat.com>
> > <mailto:sthorger at redhat.com <mailto:sthorger at 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 at redhat.com <mailto:mposolda at redhat.com>
> > <mailto:mposolda at redhat.com <mailto:mposolda at 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 at redhat.com <mailto:ssilvert at redhat.com>
> <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> > >>> <mailto:ssilvert at redhat.com
> <mailto:ssilvert at redhat.com> <mailto:ssilvert at redhat.com
> <mailto:ssilvert at 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 at redhat.com <mailto:mhajas at redhat.com>
> <mailto:mhajas at redhat.com <mailto:mhajas at redhat.com>>
> > >>> <mailto:mhajas at redhat.com
> <mailto:mhajas at redhat.com>
> > <mailto:mhajas at redhat.com <mailto:mhajas at 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/main/resources/keycloak.js#L882
> > >>> >> &
> > >>> >>
> > >>>
> >
> <https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L882&>
> > >>> >>
> > >>> >>
> > >>>
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L866
> > >>> >>
> > >>> >> [2]
> > >>> >>
> > >>> >>
> > >>>
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L617
> > >>> >> &
> > >>> >>
> > >>>
> >
> <https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L617&>
> > >>> >>
> > >>> >>
> > >>>
> >
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/js/src/main/resources/keycloak.js#L732
> > >>> >> _______________________________________________
> > >>> >> 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>>
> > <mailto: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>>
> > <mailto: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
> > >
> > > _______________________________________________
> > > 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
> >
>
> _______________________________________________
> 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
>
>
>
> --
> Václav Muzikář
> Senior Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
More information about the keycloak-dev
mailing list