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(a)redhat.com
<mailto:sthorger@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
<mailto:mposolda@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>
>>> <mailto:ssilvert@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>
>>> <mailto:mhajas@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/main/resources/keycloak.js#L882&>
>>> >>
>>> >>
>>>
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/main/resources/keycloak.js#L617&>
>>> >>
>>> >>
>>>
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@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>>> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>>> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev