8:21 a.m.
On 8 March 2016 at 15:00, John Dennis <jdennis(a)redhat.com> wrote:
On 03/08/2016 12:51 AM, Stian Thorgersen wrote:
> Client registration service can only be invoked by a user from the realm
> you are creating a client in, so users in the master realm can only
> create clients in the master realm.
>
> IMO you should use the client registration services, supported initial
> access tokens and leave realm creation to another process. Creating a
> realm is part of installing the Keycloak server, not installing the
> client.
>
I'm not asking about realm creation. Rather I'm following up on your
suggestion from a couple of days ago where you said instead of using an an
initial access token:
> You can also invoke it with the same access token (
http://keycloak.github.io/docs/userguide/keycloak-server/html/client-regi...
)
This why I referenced Chapter 9.1.1 where it says a bearer token can be
used to register the client. So my question is how does one do that?
Here are the reasons why I'm pursuing this approach:
* A process which creates a client in a realm should only have privileges
in the realm, anything that requires super admin privileges on the master
realm compromises the security of other realms hosted on the Keycloak
instance (principle of least privilege).
* Initial access tokens make automated provisioning difficult. But more to
the point far as I can tell using an initial access token still requires
super admin privileges at some point in the process. Either a super admin
(human) has to logon to the web UI and copy the initial access token into a
file for later use (and possibly exposing) or a process with super admin
privileges has to create an initial access token via the REST interface.
Remember the goal here is automated stand-alone provisioning (e.g. via
ansible or puppet) of realm specific clients *without* super admin
privileges that could compromise other realms (principle of least
privilege). This suggests there should be a realm specific admin who can
register a client (this is the fundamental question at hand).
Thus what I was trying to resolve was how to have a realm specific admin
who can only administer the realm. Initially I tried to create a user in
the realm and grant them the necessary administration roles but I was
unable to get a bearer token for that user using the realm token endpoint
and passing their credentials. Then I went back re-read the documentation
on administration privileges (cited below) which states realm
administrators must be users in the master realm hence a realm
administrator cannot use their bearer token to register a client because
cross realm tokens are prohibited.
Does this now make more sense?
Yep, I wrongly made the assumption that you wanted to use the same token to
create a realm and to create the client.
We need to figure out a way to provision initial access tokens or another
way to permit usage of client registration services, as using a user or
service account for it doesn't make to much sense.
In the mean time I'd use a service account rather than a regular user. Then
use the client credentials grant to obtain the token. The service account
only needs a role mapping on the create-client role from the
realm-management client. That way it'll only be able to create clients for
a specific realm and nothing else.
> On 8 March 2016 at 01:14, John Dennis <jdennis(a)redhat.com
> <mailto:jdennis@redhat.com>> wrote:
>
> Chapter 9.1.1 of the Keycloak Reference Guide
> (
> http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
> says that a bearer token can be used to register a client provided the
> user has the create-client or manage-client role on the realm.
>
> Chapter 6 discusses how to create a user in the master realm who can
> administer a specific realm. I followed those instructions and created
> a user and assigned them the create-client role in the desired realm.
>
> I then obtained a token for that user by posting to
> auth/realms/master/protocol/openid-connect/token with the username and
> password for the realm administrator I created along with the
> client-id of "admin-cli" (not sure if this is the right client id for
> this purpose, can someone explain selecting the proper client id?).
>
> I received back a token and then used this as an authorization bearer
> token when POSTing to the
> auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
> SP client in the realm. However this fails with an 403 Forbidden
> response and the message "Invalid signature".
>
> This error seems to be generated by the ClientRegistrationTokenUtils
> class in the method parseToken() which is called in the init() method
> of the ClientRegistrationAuth class. As far as I can tell the
> parseToken() method is using the public key for the realm. But the
> token is not from the realm, the token is from the master realm where
> the realm's admin is located.
>
> For the bearer token to work when registering a client it would seem
> the token would have belong to a user in the realm, not the master
> realm as discussed in Chapter 6.
>
> How is client creation supposed to work with a bearer token instead of
> using an initial access token?
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
--
John