[keycloak-dev] Credentials in javascript adapter

[Stian Thorgersen]

Sure,

Account client represents the REST API (and old console, but let's ignore
that ;)). The REST API is what provides a service right and is the place
that can do RBAC, hence why it's what has the roles.

So we have the above REST API that can be invoked if you have an access
token with the account::manage-account role and if the audience of the
token is the account client. The latter is a check to make sure that the
token is actually meant to be used for the account rest api.

For the new account console to be able to invoke the REST API it then needs
scope on the account::manage-account role which adds the role to the token,
and it also needs the audience-resolve thingy. The audience-resolve thingy
is a bit of magic added by Marek. What it does is that it automatically
adds audience for any clients the client has a scope for at least one
client role. So since the account console client has a scope on
account::manage-account the aud field will include account.

On Tue, 19 Nov 2019 at 15:27, Stan Silvert <ssilvert at redhat.com> wrote:

> On 11/19/2019 5:34 AM, Stian Thorgersen wrote:
>
> Added a PR with new account-console client here:
> https://github.com/keycloak/keycloak/pull/6501
>
> All roles and permissions are still associated with "account" client as
> that is what represents the Account REST API. So the only thing that is
> needed is to create a new account-console public client with the correct
> scope/audience and update index.ftl to use account-console client. Ignoring
> the migration code and tests it is a pretty simple change.
>
> That's great.  Can you enlighten us on how this actually works?  I take it
> the magic happens in AudenceResolveProtocolMapper?  I'm not clear on what
> is going on there.
>
>
>
> On Mon, 18 Nov 2019 at 20:42, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 11/18/2019 8:23 AM, Stan Silvert wrote:
>> > 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.
>> >
>> I went ahead and implemented #1.  All tests pass.
>> https://github.com/keycloak/keycloak/pull/6500
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>