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 http://www.keycloak.org/ docs-api/3.1/rest-api/index.html#_clientrepresentation - I can be sure that support of that field remain in e.g. next versions of KeyCloak? AdamLis; 2017-06-21 15:58 GMT+02:00 Marko Strukelj <mstrukel(a)redhat.com&gt;: > 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/k > eycloak/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&gt; 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&gt;: >> >> > 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&gt; 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 >> > >