[keycloak-dev] Credentials in javascript adapter
Stan Silvert
ssilvert at redhat.com
Mon Nov 18 08:23:59 EST 2019
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>> 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>> 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>>>
> 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>>> 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>>
> >>> >> 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
> >
> > _______________________________________________
> > 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
>
More information about the keycloak-dev
mailing list