Hi!
Thanks for your response.
This is indeed what I needed.
As far as I understand, since 'secret' field name is present in
ClientRepresentation in
.
html#_clientrepresentation - I can be sure that support of that field
remain in e.g. next versions of KeyCloak?
PS: Sorry Marko, I've posted a private message to you earlier.
AdamLis;
2017-06-21 15:58 GMT+02:00 Marko Strukelj <mstrukel(a)redhat.com>:
Your use case is indeed rather poorly documented, and requires some
exploration, especially when using kcadm.sh or Admin Client API you need to
also consult Admin REST API documentation (
http://www.keycloak.org/docs-
api/3.1/rest-api/index.html#_clientrepresentation) or directly explore
the code for Admin REST endpoint (
https://github.com/keycloak/
keycloak/blob/3.1.0.Final/services/src/main/java/org/
keycloak/services/resources/admin/ClientsResource.java#L146).
Here's how you can set the secret for the client:
$ cat > client.json << EOF
{
"clientId" : "test-cli",
"enabled" : true,
"clientAuthenticatorType" : "client-secret",
"secret" : "d0b8122f-8dfb-46b7-b68a-f5cc4e25d000"
}
The key here are the properties "clientAuthenticatorType", and
"secret".
You can safely get away by only setting "secret" since "client-secret'
is
default for "clientAuthenticatorType".
$ kcadm.sh create clients -r REALM_NAME -f client.json -i
If you want to check the value of secret you need to perform another REST
call as it's not returned as part of client GET.
$ kcadm.sh get clients/$CID/client-secret
Which will return CredentialRepresentation (
http://www.keycloak.org/docs-
api/3.1/rest-api/index.html#_getclientsecret):
{
"type" : "secret",
"value" : "d0b8122f-8dfb-46b7-b68a-f5cc4e25d737"
}
Hopefully that addresses your problem.
On Tue, Jun 20, 2017 at 5:07 PM, Adam Lis <adam.lis(a)gmail.com> wrote:
> Hi!
>
> Thanks for response.
>
> Re what I'd like to achieve: I'd like to give some people pair
> Client/ClientSecret so they could use my Keycloak instance. Since this
> instance gets recreated using config management utility very often (e.g. 5
> times a day), I need a functionality to be able to specify ClientSecret
> when "provisioning" Keycloak instance.
>
> So for my needs - export-import is not good solution - since my server is
> started using standalone.sh script as PID=1 inside docker container. Also
> it would be hard to execute Export in my case, since docker container
> shutdown is also done by config management system - and I'd need to start
> standalone.sh again with export set. BTW: when export/import is involved
> by
> migration.action - it seems strange that main server thread is also
> starting.
>
> So I've read
>
https://keycloak.gitbooks.io/documentation/server_admin/topi
> cs/admin-cli.html
> and
>
https://keycloak.gitbooks.io/documentation/securing_apps/top
> ics/client-registration/client-registration-cli.html
>
> In above documents there is describes process of e.g. defining new
> Clients.
> But it does not answer my question at all.
>
> So maybe once again my question: >>> Is specifying 'secret'
parameter into
> JSON creating new Client using e.g. "kcadm.sh create clients -r REALM_NAME
> -f JSON_FILE.json -i" proper and supported way of passing ClientSecret
> value to newly created Client? <<<
>
> AdamLis;
>
>
> 2017-06-20 16:17 GMT+02:00 Marko Strukelj <mstrukel(a)redhat.com>:
>
> > You can find doumentation for kcadm.sh at:
https://keycloak.gitbooks.
> > io/documentation/server_admin/topics/admin-cli.html
> >
> > Maybe for your usecase you might also want to use kcreg.sh,
> documentation
> > for which you can find at:
https://keycloak.gitbooks.
> > io/documentation/securing_apps/topics/client-registration/client-
> > registration-cli.html
> >
> > kcreg.sh is meant for use by application developers to self-provision
> > clients in order to integrate their apps with a Keycloak Server.
> >
> > There is also a boot time import functionality which you can use to
> import
> > the whole realm:
https://keycloak.gitbooks.io/documentation/
> > server_admin/topics/export-import.html
> >
> > As to your question whether you can base realm / client creation on
> > Keycloak's export / import functionality or CLI tools the answer is -
> yes,
> > that's the idea. If you can't achieve something basic and obvious then
> the
> > tools have to be improved.
> >
> > If you can be more specific what you are trying to achieve and what
> > exactly you do, then I can give you more specific advice.
> >
> > Also, if you can be more specific what you were not able to find in the
> > documentation, we can add it or make it easier to find.
> >
> > On Tue, Jun 20, 2017 at 2:24 PM, Adam Lis <adam.lis(a)gmail.com> wrote:
> >
> >> Hi!
> >>
> >> I've tried to search for this information in documentation, but not
> >> succeeded.
> >>
> >> Let's assume I'm using keycloak docker container.
> >>
> >> Inside running instance I'm willing to add new Client like this:
> >>
> >> /opt/jboss/keycloak/bin/kcadm.sh create clients -r REALM_NAME -f
> >> FILE_CONTAINING_DEFINITION.json -i
> >>
> >> So I'm getting actual contents of JSON file for example by exporting
> >> existing Client (since I see no example in documentation as well)
> >>
> >> But in the export software is not setting 'secret' value in case
> >> 'clientAuthenticatorType' is set to 'client-secret'.
> >>
> >> I've anyway tried to add 'secret' field to JSON and it has been
> accepted
> >> by
> >> Keycloak - so Keycloak has created Client with ClientSecret value
> passed
> >> by
> >> JSON file in field named 'secret'.
> >>
> >> My question and concern is: does this functionality (setting desired
> >> ClientSecret on Client creation from JSON) work intended way? Can I
> base
> >> my
> >> whole Realm/Client creation solution on that functionality?
> >>
> >> A little background: I'm willing to run Keycloak deployment with docker
> >> container as part of configuration management - so I'm storing Realm
> and
> >> Client data in outside storage and I'm willing to pass these
> configuration
> >> pieces into newly started Keycloak inside docker container.
> >>
> >> Thanks;
> >> AdamLis;
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>