12:08 a.m.
Marko,
I've just been playing with the client registration cli and it's just plain
awesome.
This:
# kcreg.sh create myclient.json
Is so much better than:
# Open admin console
# Login
# Click clients
# Click create
# Click import file
# Click save
Nice work :)
12:11 a.m.
Cool stuff!
Is there a template for client.json?
Cheers,
Thomas
Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen"
<sthorger(a)redhat.com>:
Marko,
I've just been playing with the client registration cli and it's just plain
awesome.
This:
# kcreg.sh create myclient.json
Is so much better than:
# Open admin console
# Login
# Click clients
# Click create
# Click import file
# Click save
Nice work :)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:14 a.m.
It actually supports Keycloak client rep (same as used by admin console),
OIDC client representations (
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)
as well as SAML entity descriptors.
For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
options.
You can even do:
kcreg.sh create -s clientId=test -s
redirectUris='["http://localhost","
http://localhost:8080"]'
On 19 October 2016 at 07:11, Thomas Darimont <thomas.darimont(a)googlemail.com
wrote:
Cool stuff!
Is there a template for client.json?
Cheers,
Thomas
Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen"
<sthorger(a)redhat.com>:
> Marko,
>
> I've just been playing with the client registration cli and it's just
> plain
> awesome.
>
> This:
> # kcreg.sh create myclient.json
>
> Is so much better than:
> # Open admin console
> # Login
> # Click clients
> # Click create
> # Click import file
> # Click save
>
> Nice work :)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2:16 a.m.
Hello,
ah great - I guess one could take the json from a fully configured client
as an example.
I used the following curl sequence get the client representation of an
existing client:
KC_REALM=dev
KC_USERNAME=realm-admin
KC_PASSWORD=test
KC_CLIENT=admin-client
KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
KC_SERVER=https://test-sso
KC_CONTEXT=auth
CURL_OPTS="-k -v --noproxy 192.168.99.1"
# Request Tokens for credentials
KC_RESPONSE=$( \
curl $CURL_OPTS -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=$KC_USERNAME" \
-d "password=$KC_PASSWORD" \
-d 'grant_type=password' \
-d "client_id=$KC_CLIENT" \
-d "client_secret=$KC_CLIENT_SECRET" \
"$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" \
| jq .
)
KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
CLIENT_CLIENTID=myapp
curl -v \
-k \
-H "Authorization: Bearer $KC_ACCESS_TOKEN" \
$KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-registrations/default/$CLIENT_CLIENTID
\
| jq .
Cheers,
Thomas
2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
It actually supports Keycloak client rep (same as used by admin
console),
OIDC client representations (https://openid.net/specs/
openid-connect-registration-1_0.html#ClientMetadata) as well as SAML
entity descriptors.
For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
options.
You can even do:
kcreg.sh create -s clientId=test -s
redirectUris='["http://localhost","
http://localhost:8080"]'
On 19 October 2016 at 07:11, Thomas Darimont <thomas.darimont@googlemail.
com> wrote:
> Cool stuff!
>
> Is there a template for client.json?
>
> Cheers,
> Thomas
>
> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen"
<sthorger(a)redhat.com
> >:
>
>> Marko,
>>
>> I've just been playing with the client registration cli and it's just
>> plain
>> awesome.
>>
>> This:
>> # kcreg.sh create myclient.json
>>
>> Is so much better than:
>> # Open admin console
>> # Login
>> # Click clients
>> # Click create
>> # Click import file
>> # Click save
>>
>> Nice work :)
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
4:40 a.m.
Thanks Stian!
It took a while to get it to this point, but hopefully it will suit well
different needs and scripting styles, and get used a lot.
There are still bugs in there I'm sure :)
Next on the list - Admin CLI ...
On Wed, Oct 19, 2016 at 9:16 AM, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hello,
ah great - I guess one could take the json from a fully configured client
as an example.
I used the following curl sequence get the client representation of an
existing client:
KC_REALM=dev
KC_USERNAME=realm-admin
KC_PASSWORD=test
KC_CLIENT=admin-client
KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
KC_SERVER=https://test-sso
KC_CONTEXT=auth
CURL_OPTS="-k -v --noproxy 192.168.99.1"
# Request Tokens for credentials
KC_RESPONSE=$( \
curl $CURL_OPTS -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=$KC_USERNAME" \
-d "password=$KC_PASSWORD" \
-d 'grant_type=password' \
-d "client_id=$KC_CLIENT" \
-d "client_secret=$KC_CLIENT_SECRET" \
"$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token"
\
| jq .
)
KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
CLIENT_CLIENTID=myapp
curl -v \
-k \
-H "Authorization: Bearer $KC_ACCESS_TOKEN" \
$KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-
registrations/default/$CLIENT_CLIENTID \
| jq .
Cheers,
Thomas
2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
> It actually supports Keycloak client rep (same as used by admin console),
> OIDC client representations (https://openid.net/specs/open
> id-connect-registration-1_0.html#ClientMetadata) as well as SAML entity
> descriptors.
>
> For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
> options.
>
> You can even do:
>
> kcreg.sh create -s clientId=test -s
redirectUris='["http://localhost","
> http://localhost:8080"]'
>
> On 19 October 2016 at 07:11, Thomas Darimont <
> thomas.darimont(a)googlemail.com> wrote:
>
>> Cool stuff!
>>
>> Is there a template for client.json?
>>
>> Cheers,
>> Thomas
>>
>> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen"
<sthorger(a)redhat.com
>> >:
>>
>>> Marko,
>>>
>>> I've just been playing with the client registration cli and it's
just
>>> plain
>>> awesome.
>>>
>>> This:
>>> # kcreg.sh create myclient.json
>>>
>>> Is so much better than:
>>> # Open admin console
>>> # Login
>>> # Click clients
>>> # Click create
>>> # Click import file
>>> # Click save
>>>
>>> Nice work :)
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
4:58 a.m.
Thomas, you would now do the same using something like:
Set up truststore ($KC_TRUSTSTORE is path to .jks file with certificates
you trust):
$ kcreg.sh config truststore $KC_TRUSTSTORE --trustpass $KC_TRUSTPASS
Login:
$ kcreg.sh config credentials --server $KC_SERVER/$KC_CONTEXT --realm
$KC_REALM --user $KC_USERNAME --password $KC_PASSWORD --client $KC_CLIENT
--secret $KC_CLIENT_SECRET
And then you can do as many CRUD operations as you like:
$ kcreg.sh get $CLIENT_CLIENTID
Or if you just want a simple one liner you can actually put all the
parameters on a single command line, and make sure nothing (meaning tokens,
and secrets) is saved in private config file:
$ kcreg.sh get --no-config --server $KC_SERVER/$KC_CONTEXT --realm
$KC_REALM --user $KC_USERNAME --password $KC_PASSWORD --client $KC_CLIENT
--secret $KC_CLIENT_SECRET --truststore $KC_TRUSTSTORE --trustpass
$KC_TRUSTPASS $CLIENT_CLIENTID
On Wed, Oct 19, 2016 at 9:16 AM, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hello,
ah great - I guess one could take the json from a fully configured client
as an example.
I used the following curl sequence get the client representation of an
existing client:
KC_REALM=dev
KC_USERNAME=realm-admin
KC_PASSWORD=test
KC_CLIENT=admin-client
KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
KC_SERVER=https://test-sso
KC_CONTEXT=auth
CURL_OPTS="-k -v --noproxy 192.168.99.1"
# Request Tokens for credentials
KC_RESPONSE=$( \
curl $CURL_OPTS -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=$KC_USERNAME" \
-d "password=$KC_PASSWORD" \
-d 'grant_type=password' \
-d "client_id=$KC_CLIENT" \
-d "client_secret=$KC_CLIENT_SECRET" \
"$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token"
\
| jq .
)
KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
CLIENT_CLIENTID=myapp
curl -v \
-k \
-H "Authorization: Bearer $KC_ACCESS_TOKEN" \
$KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-
registrations/default/$CLIENT_CLIENTID \
| jq .
Cheers,
Thomas
2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
> It actually supports Keycloak client rep (same as used by admin console),
> OIDC client representations (https://openid.net/specs/open
> id-connect-registration-1_0.html#ClientMetadata) as well as SAML entity
> descriptors.
>
> For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
> options.
>
> You can even do:
>
> kcreg.sh create -s clientId=test -s
redirectUris='["http://localhost","
> http://localhost:8080"]'
>
> On 19 October 2016 at 07:11, Thomas Darimont <
> thomas.darimont(a)googlemail.com> wrote:
>
>> Cool stuff!
>>
>> Is there a template for client.json?
>>
>> Cheers,
>> Thomas
>>
>> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen"
<sthorger(a)redhat.com
>> >:
>>
>>> Marko,
>>>
>>> I've just been playing with the client registration cli and it's
just
>>> plain
>>> awesome.
>>>
>>> This:
>>> # kcreg.sh create myclient.json
>>>
>>> Is so much better than:
>>> # Open admin console
>>> # Login
>>> # Click clients
>>> # Click create
>>> # Click import file
>>> # Click save
>>>
>>> Nice work :)
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
2990
days inactive
2990
days old
5 comments
3 participants
participants (3)
-
Marko Strukelj -
Stian Thorgersen -
Thomas Darimont