Chapter 19. The Admin CLI

The Admin CLI is packaged inside Red Hat Single Sign-On Server distribution. You can find execution scripts inside the bin directory.

The Linux script is called kcadm.sh, and the script for Windows is called kcadm.bat.

You can add the Red Hat Single Sign-On server directory to your PATH to use the client from any location on your file system.

For example, on:

$ export PATH=$PATH:$KEYCLOAK_HOME/bin
$ kcadm.sh

c:\> set PATH=%PATH%;%KEYCLOAK_HOME%\bin
c:\> kcadm

We assume the KEYCLOAK_HOME environment (env) variable is set to the path where you extracted the Red Hat Single Sign-On Server distribution.

The Admin CLI works by making HTTP requests to Admin REST endpoints. Access to them is protected and requires authentication.

When you log in with the Admin CLI, you specify a server endpoint URL and a realm, and then you specify a user name. Another option is to specify only a clientId, which results in using a special "service account". When you log in using a user name, you must use a password for the specified user. When you log in using a clientId, you only need the client secret, not the user password. You could also use Signed JWT instead of the client secret.

Make sure the account used for the session has the proper permissions to invoke Admin REST API operations. For example, the realm-admin role of the realm-management client allows the user to administer the realm within which the user is defined.

There are two primary mechanisms for authentication. One mechanism uses kcadm config credentials to start an authenticated session.

$ kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin --password admin

This approach maintains an authenticated session between the kcadm command invocations by saving the obtained access token and the associated refresh token. It may also maintain other secrets in a private configuration file. See next chapter for more information on the configuration file.

The second approach only authenticates each command invocation for the duration of that invocation. This approach increases the load on the server and the time spent with roundtrips obtaining tokens. The benefit of this approach is not needing to save any tokens between invocations, which means nothing is saved to disk. This mode is used when the --no-config argument is specified.

For example, when performing an operation, we specify all the information required for authentication.

$ kcadm.sh get realms --no-config --server http://localhost:8080/auth --realm master --user admin --password admin

Run the kcadm.sh help command for more information on using the Admin CLI.

Run the kcadm.sh config credentials --help command for more information about starting an authenticated session.

By default, the Admin CLI automatically maintains a configuration file called kcadm.config located under the user’s home directory. In Linux-based systems, the full path name is $HOME/.keycloak/kcadm.config. On Windows, the full path name is %HOMEPATH%\.keycloak\kcadm.config. You can use the --config option to point to a different file or location so you can maintain multiple authenticated sessions in parallel.

Make sure you do not make the configuration file visible to other users on the system. It contains access tokens and secrets that should be kept private. By default, the ~/.keycloak directory and its content are created automatically with proper access limits. If the directory already exists, its permissions are not updated.

If your unique circumstances require you to avoid storing secrets inside a configuration file, you can do so. It will be less convenient and you will have to make more token requests. To not store secrets, use the --no-config option with all your commands and specify all the authentication information needed by the config credentials command with each kcadm invocation.

The Admin CLI allows you to generically perform CRUD operations against Admin REST API endpoints with additional commands that simplify performing certain tasks.

The main usage pattern is listed below, where the create, get, update, and delete commands are mapped to the HTTP verbs POST, GET, PUT, and DELETE, respectively.

$ kcadm.sh create ENDPOINT [ARGUMENTS]
$ kcadm.sh get ENDPOINT [ARGUMENTS]
$ kcadm.sh update ENDPOINT [ARGUMENTS]
$ kcadm.sh delete ENDPOINT [ARGUMENTS]

ENDPOINT is a target resource URI and can either be absolute (starting with http: or https:) or relative, used to compose an absolute URL of the following format:

SERVER_URI/admin/realms/REALM/ENDPOINT

For example, if you authenticate against the server http://localhost:8080/auth and realm is master, then using users as ENDPOINT results in the resource URL http://localhost:8080/auth/admin/realms/master/users.

If you set ENDPOINT to clients, the effective resource URI would be http://localhost:8080/auth/admin/realms/master/clients.

There is a realms endpoint that is treated slightly differently because it is the container for realms. It resolves to:

SERVER_URI/admin/realms

There is also a serverinfo endpoint, which is treated the same way because it is independent of realms.

When you authenticate as a user with realm-admin powers, you might need to perform commands on multiple realms. In that case, specify the -r option to tell explicitly which realm the command should be executed against. Instead of using REALM as specified via the --realm option of kcadm.sh config credentials, the TARGET_REALM is used.

SERVER_URI/admin/realms/TARGET_REALM/ENDPOINT

For example,

$ kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin --password admin
$ kcadm.sh create users -s username=testuser -s enabled=true -r demorealm

In this example, you start a session authenticated as the admin user in the master realm. You then perform a POST call against the resource URL http://localhost:8080/auth/admin/realms/demorealm/users.

The create and update commands send a JSON body to the server by default. You can use -f FILENAME to read a premade document from a file. When you can use -f - option, the message body is read from standard input. You can also specify individual attributes and their values as seen in the previous create users example. They are composed into a JSON body and sent to the server.

There are several ways to update a resource using the update command. You can first determine the current state of a resource and save it to a file, and then edit that file and send it to the server for updating.

For example:

$ kcadm.sh get realms/demorealm > demorealm.json
$ vi demorealm.json
$ kcadm.sh update realms/demorealm -f demorealm.json

This method updates the resource on the server with all the attributes in the sent JSON document.

Another option is to perform an on-the-fly update using the -s, --set options to set new values.

For example:

$ kcadm.sh update realms/demorealm -s enabled=false

That method only updates the enabled attribute to false.

By default, the update command first performs a get and then merges the new attribute values with existing values. This is the preferred behavior. In some cases, the endpoint may support the PUT command but not the GET command. You can use the -n option to perform a "no-merge" update, which performs a PUT command without first running a GET command.

Creating a new realm

Use the create command on the realms endpoint to create a new enabled realm, and set the attributes to realm and enabled.

$ kcadm.sh create realms -s realm=demorealm -s enabled=true

A realm is not enabled by default. By enabling it, you can use a realm immediately for authentication.

A description for a new object can also be in a JSON format.

$ kcadm.sh create realms -f demorealm.json

You can send a JSON document with realm attributes directly from a file or piped to a standard input.

For example, on:

$ kcadm.sh create realms -f - << EOF
{ "realm": "demorealm", "enabled": true }
EOF

c:\> echo { "realm": "demorealm", "enabled": true } | kcadm create realms -f -

Listing existing realms

The following command returns a list of all realms.

$ kcadm.sh get realms

Returning the entire realm description often provides too much information. Most users are interested only in a subset of attributes, such as realm name and whether the realm is enabled. You can specify which attributes to return by using the --fields option.

$ kcadm.sh get realms --fields realm,enabled

You can also display the result as comma separated values.

$ kcadm.sh get realms --fields realm --format csv --noquotes

Getting a specific realm

You append a realm name to a collection URI to get an individual realm.

$ kcadm.sh get realms/master

Updating a realm

Deleting a realm

Run the following command to delete a realm.

$ kcadm.sh delete realms/demorealm

Turning on all login page options for the realm

Set the attributes controlling specific capabilities to true.

For example:

$ kcadm.sh update realms/demorealm -s registrationAllowed=true -s registrationEmailAsUsername=true -s rememberMe=true -s verifyEmail=true -s resetPasswordAllowed=true -s editUsernameAllowed=true

Listing the realm keys

Use the get operation on the keys endpoint of the target realm.

$ kcadm.sh get keys -r demorealm

Generating new realm keys

Adding new realm keys from a Java Key Store file

Making the key passive or disabling the key

Deleting an old key

Configuring event logging for a realm

Use the update command on the events/config endpoint.

The eventsListeners attribute contains a list of EventListenerProviderFactory IDs that specify all event listeners receiving events. Separately, there are attributes that control a built-in event storage, which allows querying past events via the Admin REST API. There is separate control over logging of service calls (eventsEnabled) and auditing events triggered during Admin Console or Admin REST API (adminEventsEnabled). You may want to set up expiry of old events so that your database does not fill up; eventsExpiration is set to time-to-live expressed in seconds.

Here is an example of setting up a built-in event listener that receives all the events and logs them through jboss-logging. (Using a logger called org.keycloak.events, error events are logged as WARN, and others are logged as DEBUG.)

For example, on:

$ kcadm.sh update events/config -r demorealm -s 'eventsListeners=["jboss-logging"]'

c:\> kcadm update events/config -r demorealm -s "eventsListeners=[\"jboss-logging\"]"

Here is an example of turning on storage of all available ERROR events—not including auditing events—for 2 days so they can be retrieved via Admin REST.

For example, on:

$ kcadm.sh update events/config -r demorealm -s eventsEnabled=true -s 'enabledEventTypes=["LOGIN_ERROR","REGISTER_ERROR","LOGOUT_ERROR","CODE_TO_TOKEN_ERROR","CLIENT_LOGIN_ERROR","FEDERATED_IDENTITY_LINK_ERROR","REMOVE_FEDERATED_IDENTITY_ERROR","UPDATE_EMAIL_ERROR","UPDATE_PROFILE_ERROR","UPDATE_PASSWORD_ERROR","UPDATE_TOTP_ERROR","VERIFY_EMAIL_ERROR","REMOVE_TOTP_ERROR","SEND_VERIFY_EMAIL_ERROR","SEND_RESET_PASSWORD_ERROR","SEND_IDENTITY_PROVIDER_LINK_ERROR","RESET_PASSWORD_ERROR","IDENTITY_PROVIDER_FIRST_LOGIN_ERROR","IDENTITY_PROVIDER_POST_LOGIN_ERROR","CUSTOM_REQUIRED_ACTION_ERROR","EXECUTE_ACTIONS_ERROR","CLIENT_REGISTER_ERROR","CLIENT_UPDATE_ERROR","CLIENT_DELETE_ERROR"]' -s eventsExpiration=172800

c:\> kcadm update events/config -r demorealm -s eventsEnabled=true -s "enabledEventTypes=[\"LOGIN_ERROR\",\"REGISTER_ERROR\",\"LOGOUT_ERROR\",\"CODE_TO_TOKEN_ERROR\",\"CLIENT_LOGIN_ERROR\",\"FEDERATED_IDENTITY_LINK_ERROR\",\"REMOVE_FEDERATED_IDENTITY_ERROR\",\"UPDATE_EMAIL_ERROR\",\"UPDATE_PROFILE_ERROR\",\"UPDATE_PASSWORD_ERROR\",\"UPDATE_TOTP_ERROR\",\"VERIFY_EMAIL_ERROR\",\"REMOVE_TOTP_ERROR\",\"SEND_VERIFY_EMAIL_ERROR\",\"SEND_RESET_PASSWORD_ERROR\",\"SEND_IDENTITY_PROVIDER_LINK_ERROR\",\"RESET_PASSWORD_ERROR\",\"IDENTITY_PROVIDER_FIRST_LOGIN_ERROR\",\"IDENTITY_PROVIDER_POST_LOGIN_ERROR\",\"CUSTOM_REQUIRED_ACTION_ERROR\",\"EXECUTE_ACTIONS_ERROR\",\"CLIENT_REGISTER_ERROR\",\"CLIENT_UPDATE_ERROR\",\"CLIENT_DELETE_ERROR\"]" -s eventsExpiration=172800

Here is an example of how to reset stored event types to all available event types; setting to empty list is the same as enumerating all.

$ kcadm.sh update events/config -r demorealm -s enabledEventTypes=[]

Here is an example of how to enable storage of auditing events.

$ kcadm.sh update events/config -r demorealm -s adminEventsEnabled=true -s adminEventsDetailsEnabled=true

Here is an example of how to get the last 100 events; they are ordered from newest to oldest.

$ kcadm.sh get events --offset 0 --limit 100

Here is an example of how to delete all saved events.

$ kcadm delete events

Flushing the caches

Importing a realm from exported .json file

Creating a realm role

Use the roles endpoint to create a realm role.

$ kcadm.sh create roles -r demorealm -s name=user -s 'description=Regular user with limited set of permissions'

Creating a client role

Listing realm roles

Use the get command on the roles endpoint to list existing realm roles.

$ kcadm.sh get roles -r demorealm

You can also use the get-roles command.

$ kcadm.sh get-roles -r demorealm

Listing client roles

There is a dedicated get-roles command to simplify listing realm and client roles. It is an extension of the get command and behaves the same with additional semantics for listing roles.

Use the get-roles command, passing it either the clientId attribute (via the --cclientid option) or id (via the --cid option) to identify the client to list client roles.

For example:

$ kcadm.sh get-roles -r demorealm --cclientid realm-management

Getting a specific realm role

Use the get command and the role name to construct an endpoint URI for a specific realm role: roles/ROLE_NAME, where user is the name of the existing role.

For example:

$ kcadm.sh get roles/user -r demorealm

You can also use the special get-roles command, passing it a role name (via the --rolename option) or ID (via the --roleid option).

For example:

$ kcadm.sh get-roles -r demorealm --rolename user

Getting a specific client role

Use a dedicated get-roles command, passing it either the clientId attribute (via the --cclientid option) or ID (via the --cid option) to identify the client, and passing it either the role name (via the --rolename option) or ID (via the --roleid) to identify a specific client role.

For example:

$ kcadm.sh get-roles -r demorealm --cclientid realm-management --rolename manage-clients

Updating a realm role

Use the update command with the same endpoint URI that you used to get a specific realm role.

For example:

$ kcadm.sh update roles/user -r demorealm -s 'description=Role representing a regular user'

Updating a client role

Use the update command with the same endpoint URI that you used to get a specific client role.

For example:

$ kcadm.sh update clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm -s 'description=User that can edit, and publish articles'

Deleting a realm role

Use the delete command with the same endpoint URI that you used to get a specific realm role.

For example:

$ kcadm.sh delete roles/user -r demorealm

Deleting a client role

Use the delete command with the same endpoint URI that you used to get a specific client role.

For example:

$ kcadm.sh delete clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm

Listing assigned, available, and effective realm roles for a composite role

Use a dedicated get-roles command to list assigned, available, and effective realm roles for a composite role.

Listing assigned, available, and effective client roles for a composite role

Use a dedicated get-roles command to list assigned, available, and effective client roles for a composite role.

Adding realm roles to a composite role

There is a dedicated add-roles command that can be used for adding realm roles and client roles.

The following example adds the user role to the composite role testrole.

$ kcadm.sh add-roles --rname testrole --rolename user -r demorealm

Removing realm roles from a composite role

There is a dedicated remove-roles command that can be used to remove realm roles and client roles.

The following example removes the user role from the target composite role testrole.

$ kcadm.sh remove-roles --rname testrole --rolename user -r demorealm

Adding client roles to a realm role

Use a dedicated add-roles command that can be used for adding realm roles and client roles.

The following example adds the roles defined on the client realm-management - create-client role and the view-users role to the testrole composite role.

$ kcadm.sh add-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users

Adding client roles to a client role

Removing client roles from a composite role

Use a dedicated remove-roles command to remove client roles from a composite role.

Use the following example to remove two roles defined on the client realm management - create-client role and the view-users role from the testrole composite role.

$ kcadm.sh remove-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users

Adding client roles to a group

Use a dedicated add-roles command that can be used for adding realm roles and client roles.

The following example adds the roles defined on the client realm-management - create-client role and the view-users role to the Group group (via the --gname option). The group can alternatively be specified by ID (via the --gid option).

See Group operations for more operations that can be performed to groups.

$ kcadm.sh add-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users

Removing client roles from a group

Use a dedicated remove-roles command to remove client roles from a group.

Use the following example to remove two roles defined on the client realm management - create-client role and the view-users role from the Group group.

See Group operations for more operations that can be performed to groups.

$ kcadm.sh remove-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users

Creating a client

Listing clients

Use the get command on the clients endpoint to list clients.

For example:

$ kcadm.sh get clients -r demorealm --fields id,clientId

This example filters the output to list only the id and clientId attributes.

Getting a specific client

Use a client’s ID to construct an endpoint URI that targets a specific client, such as clients/ID.

For example:

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm

Getting the current secret for a specific client

Use a client’s ID to construct an endpoint URI, such as clients/ID/client-secret.

For example:

$ kcadm.sh get clients/$CID/client-secret

Getting an adapter configuration file (keycloak.json) for a specific client

Use a client’s ID to construct an endpoint URI that targets a specific client, such as clients/ID/installation/providers/keycloak-oidc-keycloak-json.

For example:

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-keycloak-json -r demorealm

Getting a WildFly subsystem adapter configuration for a specific client

Use a client’s ID to construct an endpoint URI that targets a specific client, such as clients/ID/installation/providers/keycloak-oidc-jboss-subsystem.

For example:

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-jboss-subsystem -r demorealm

Getting a Docker-v2 example configuration for a specific client

Use a client’s ID to construct an endpoint URI that targets a specific client, such as clients/ID/installation/providers/docker-v2-compose-yaml.

Note that response will be in .zip format.

For example:

$ kcadm.sh get http://localhost:8080/auth/admin/realms/demorealm/clients/8f271c35-44e3-446f-8953-b0893810ebe7/installation/providers/docker-v2-compose-yaml -r demorealm > keycloak-docker-compose-yaml.zip

Updating a client

Use the update command with the same endpoint URI that you used to get a specific client.

For example, on:

$ kcadm.sh update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s 'redirectUris=["http://localhost:8080/myapp/*"]' -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp

c:\> kcadm update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s "redirectUris=[\"http://localhost:8080/myapp/*\"]" -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp

Deleting a client

Use the delete command with the same endpoint URI that you used to get a specific client.

For example:

$ kcadm.sh delete clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm

Adding or removing roles for client’s service account

Service account for the client is just a special kind of user account with username service-account-CLIENT_ID. You can perform user operations on this account as if it was a regular user.

Creating a user

Run the create command on the users endpoint to create a new user.

For example:

$ kcadm.sh create users -r demorealm -s username=testuser -s enabled=true

Listing users

Use the users endpoint to list users. The target user will have to change the password the next time they log in.

For example:

$ kcadm.sh get users -r demorealm --offset 0 --limit 1000

You can filter users by username, firstName, lastName, or email.

For example:

$ kcadm.sh get users -r demorealm -q email=google.com
$ kcadm.sh get users -r demorealm -q username=testuser

You can also filter across multiple attributes by specifying multiple -q options, which return only users that match the condition for all the attributes.

Getting a specific user

Use a user’s ID to compose an endpoint URI, such as users/USER_ID.

For example:

$ kcadm.sh get users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm

Updating a user

Use the update command with the same endpoint URI that you used to get a specific user.

For example, on:

$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s 'requiredActions=["VERIFY_EMAIL","UPDATE_PROFILE","CONFIGURE_TOTP","UPDATE_PASSWORD"]'

c:\> kcadm update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s "requiredActions=[\"VERIFY_EMAIL\",\"UPDATE_PROFILE\",\"CONFIGURE_TOTP\",\"UPDATE_PASSWORD\"]"

Deleting a user

Use the delete command with the same endpoint URI that you used to get a specific user.

For example:

$ kcadm.sh delete users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm

Resetting a user’s password

Use the dedicated set-password command to reset a user’s password.

For example:

$ kcadm.sh set-password -r demorealm --username testuser --new-password NEWPASSWORD --temporary

That command sets a temporary password for the user. The target user will have to change the password the next time they log in.

You can use --userid if you want to specify the user by using the id attribute.

You can achieve the same result using the update command on an endpoint constructed from the one you used to get a specific user, such as users/USER_ID/reset-password.

For example:

$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2/reset-password -r demorealm -s type=password -s value=NEWPASSWORD -s temporary=true -n

The last parameter (-n) ensures that only the PUT command is performed without a prior GET command. It is necessary in this instance because the reset-password endpoint does not support GET.

Listing assigned, available, and effective realm roles for a user

You can use a dedicated get-roles command to list assigned, available, and effective realm roles for a user.

$ kcadm.sh get-roles -r demorealm --uusername testuser

Listing assigned, available, and effective client roles for a user

Use a dedicated get-roles command to list assigned, available, and effective client roles for a user.

Adding realm roles to a user

Use a dedicated add-roles command to add realm roles to a user.

Use the following example to add the user role to user testuser.

$ kcadm.sh add-roles --uusername testuser --rolename user -r demorealm

Removing realm roles from a user

Use a dedicated remove-roles command to remove realm roles from a user.

Use the following example to remove the user role from the user testuser.

$ kcadm.sh remove-roles --uusername testuser --rolename user -r demorealm

Adding client roles to a user

Use a dedicated add-roles command to add client roles to a user.

Use the following example to add two roles defined on the client realm management - create-client role and the view-users role to the user testuser.

$ kcadm.sh add-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users

Removing client roles from a user

Use a dedicated remove-roles command to remove client roles from a user.

Use the following example to remove two roles defined on the realm management client.

$ kcadm.sh remove-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users

Listing a user’s sessions

Logging out a user from a specific session

Logging out a user from all sessions

You need a user’s ID to construct an endpoint URI, such as users/ID/logout.

Use the create command to perform POST on that endpoint URI.

For example:

$ kcadm.sh create users/6da5ab89-3397-4205-afaa-e201ff638f9e/logout -r demorealm -s realm=demorealm -s user=6da5ab89-3397-4205-afaa-e201ff638f9e

Creating a group

Use the create command on the groups endpoint to create a new group.

For example:

$ kcadm.sh create groups -r demorealm -s name=Group

Listing groups

Use the get command on the groups endpoint to list groups.

For example:

$ kcadm.sh get groups -r demorealm

Getting a specific group

Use the group’s ID to construct an endpoint URI, such as groups/GROUP_ID.

For example:

$ kcadm.sh get groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm

Updating a group

Use the update command with the same endpoint URI that you used to get a specific group.

For example:

$ kcadm.sh update groups/51204821-0580-46db-8f2d-27106c6b5ded -s 'attributes.email=["group@example.com"]' -r demorealm

Deleting a group

Use the delete command with the same endpoint URI that you used to get a specific group.

For example:

$ kcadm.sh delete groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm

Creating a subgroup

Find the ID of the parent group by listing groups, and then use that ID to construct an endpoint URI, such as groups/GROUP_ID/children.

For example:

$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s name=SubGroup

Moving a group under another group

For example:

$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s id=08d410c6-d585-4059-bb07-54dcb92c5094

Get groups for a specific user

Use a user’s ID to determine a user’s membership in groups to compose an endpoint URI, such as users/USER_ID/groups.

For example:

$ kcadm.sh get users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups -r demorealm

Adding a user to a group

Use the update command with an endpoint URI composed from user’s ID and a group’s ID, such as users/USER_ID/groups/GROUP_ID, to add a user to a group.

For example:

$ kcadm.sh update users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm -s realm=demorealm -s userId=b544f379-5fc4-49e5-8a8d-5cfb71f46f53 -s groupId=ce01117a-7426-4670-a29a-5c118056fe20 -n

Removing a user from a group

Use the delete command on the same endpoint URI as used for adding a user to a group, such as users/USER_ID/groups/GROUP_ID, to remove a user from a group.

For example:

$ kcadm.sh delete users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm

Listing assigned, available, and effective realm roles for a group

Use a dedicated get-roles command to list assigned, available, and effective realm roles for a group.

Listing assigned, available, and effective client roles for a group

Use a dedicated get-roles command to list assigned, available, and effective client roles for a group.

Listing available identity providers

Use the serverinfo endpoint to list available identity providers.

For example:

$ kcadm.sh get serverinfo -r demorealm --fields 'identityProviders(*)'

Listing configured identity providers

Use the identity-provider/instances endpoint.

For example:

$ kcadm.sh get identity-provider/instances -r demorealm --fields alias,providerId,enabled

Getting a specific configured identity provider

Use the alias attribute of the identity provider to construct an endpoint URI, such as identity-provider/instances/ALIAS, to get a specific identity provider.

For example:

$ kcadm.sh get identity-provider/instances/facebook -r demorealm

Removing a specific configured identity provider

Use the delete command with the same endpoint URI that you used to get a specific configured identity provider to remove a specific configured identity provider.

For example:

$ kcadm.sh delete identity-provider/instances/facebook -r demorealm

Configuring a Keycloak OpenID Connect identity provider

Configuring an OpenID Connect identity provider

Configure the generic OpenID Connect provider the same way you configure the Keycloak OpenID Connect provider, except that you set the providerId attribute value to oidc.

Configuring a SAML 2 identity provider

For example:

$ kcadm.sh create identity-provider/instances -r demorealm -s alias=saml -s providerId=saml -s enabled=true -s 'config.useJwksUrl="true"' -s config.singleSignOnServiceUrl=http://localhost:8180/auth/realms/saml-broker-realm/protocol/saml -s config.nameIDPolicyFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent -s config.signatureAlgorithm=RSA_SHA256

Configuring a Facebook identity provider

Configuring a Google identity provider

Configuring a Twitter identity provider

Configuring a GitHub identity provider

Configuring a LinkedIn identity provider

Configuring a Microsoft Live identity provider

Configuring a StackOverflow identity provider

Configuring a Kerberos storage provider

Configuring an LDAP user storage provider

Removing a user storage provider instance

Triggering synchronization of all users for a specific user storage provider

Triggering synchronization of changed users for a specific user storage provider

Test LDAP user storage connectivity

Test LDAP user storage authentication

Adding a hardcoded role LDAP mapper

Adding an MS Active Directory mapper

Adding a user attribute LDAP mapper

Adding a group LDAP mapper

Adding a full name LDAP mapper

Setting a password policy

Getting the current password policy

Get the current realm configuration and filter everything but the passwordPolicy attribute.

Use the following example to display passwordPolicy for demorealm.

$ kcadm.sh get realms/demorealm --fields passwordPolicy

Listing authentication flows

Run the get command on the authentication/flows endpoint.

For example:

$ kcadm.sh get authentication/flows -r demorealm

Getting a specific authentication flow

Run the get command on the authentication/flows/FLOW_ID endpoint.

For example:

$ kcadm.sh get authentication/flows/febfd772-e1a1-42fb-b8ae-00c0566fafb8 -r demorealm

Listing executions for a flow

Run the get command on the authentication/flows/FLOW_ALIAS/executions endpoint.

For example:

$ kcadm.sh get authentication/flows/Copy%20of%20browser/executions -r demorealm

Adding configuration to an execution

For example:

$ kcadm create "authentication/executions/a3147129-c402-4760-86d9-3f2345e401c7/config" -r examplerealm -b '{"config":{"x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.crl-checking-enabled":"","x509-cert-auth.crldp-checking-enabled":false,"x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.ocsp-checking-enabled":"","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.keyusage":"","x509-cert-auth.extendedkeyusage":"","x509-cert-auth.confirmation-page-disallowed":""},"alias":"my_otp_config"}'

Getting configuration for an execution

For example:

$ kcadm get "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm

Updating configuration for an execution

For example:

$ kcadm update "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm -b '{"id":"dd91611a-d25c-421a-87e2-227c18421833","alias":"my_otp_config","config":{"x509-cert-auth.extendedkeyusage":"","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.crl-checking-enabled":"true","x509-cert-auth.confirmation-page-disallowed":"","x509-cert-auth.keyusage":"","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.crldp-checking-enabled":"false","x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.ocsp-checking-enabled":""}}'

Deleting configuration for an execution

For example:

$ kcadm delete "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm