On 8 March 2016 at 15:00, John Dennis <jdennis@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-registration.html#d4e1458)

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@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@lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/keycloak-dev




--
John