Chapter 18. Admin CLI

Red Hat build of Keycloak packages the Admin CLI server distribution with the execution scripts in the bin directory.

The Linux script is called kcadm.sh, and the script for Windows is called kcadm.bat. Add the Red Hat build of Keycloak server directory to your PATH to use the client from any location on your file system.

For example:

The Admin CLI makes HTTP requests to Admin REST endpoints. Access to the Admin REST endpoints requires authentication.

Sensitive values, such as passwords, may be specified as command options. That is generally not recommended. There are also mechanisms by which you can be prompted for the sensitive value by either omitting the option or providing a value. Finally all will have a corresponding env variable that can be used instead. Check the help of the command you are running to see all possible options.

When you log in with the Admin CLI, you specify:

Another option is to specify a clientId only, which creates a unique service account for you to use.

When you log in using a user name, use a password for the specified user. When you log in using a clientId, you need the client secret only, not the user password. You can also use the Signed JWT rather than the client secret.

Ensure 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 can administer the realm of the user.

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

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

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

The second mechanism authenticates each command invocation for the duration of the invocation. This mechanism increases the load on the server and the time spent on round trips obtaining tokens. The benefit of this approach is that it is unnecessary to save tokens between invocations, so nothing is saved to disk. Red Hat build of Keycloak uses this mode when the --no-config argument is specified.

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

$ kcadm.sh get realms --no-config --server http://localhost:8080 --realm master --user 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.

If you do not specify the --password option (it is generally recommended to not provide passwords as part of the command), you will be prompted for a password unless one is specified as the environment variable KC_CLI_PASSWORD.

By default, the Admin CLI maintains a configuration file named kcadm.config. Red Hat build of Keycloak places this file in the user’s home directory. In Linux-based systems, the full pathname is $HOME/.keycloak/kcadm.config. In Windows, the full pathname 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.

Ensure the configuration file is invisible to other users on the system. It contains access tokens and secrets that must be private. Red Hat build of Keycloak creates the ~/.keycloak directory and its contents automatically with proper access limits. If the directory already exists, Red Hat build of Keycloak does not update the directory’s permissions.

It is possible to avoid storing secrets inside a configuration file, but doing so is inconvenient and increases the number of token requests. Use the --no-config option with all commands and specify the authentication information the config credentials command requires with each invocation of kcadm.

The Admin CLI can generically perform CRUD operations against Admin REST API endpoints with additional commands that simplify particular tasks.

The main usage pattern is listed here:

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

The create, get, update, and delete commands map to the HTTP verbs POST, GET, PUT, and DELETE, respectively. ENDPOINT is a target resource URI and can be absolute (starting with http: or https:) or relative, that Red Hat build of Keycloak uses to compose absolute URLs in the following format:

SERVER_URI/admin/realms/REALM/ENDPOINT

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

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

Red Hat build of Keycloak has a realms endpoint that is the container for realms. It resolves to:

SERVER_URI/admin/realms

Red Hat build of Keycloak has a serverinfo endpoint. This endpoint is independent of realms.

When you authenticate as a user with realm-admin powers, you may need to perform commands on multiple realms. If so, specify the -r option to tell the CLI which realm the command is to execute against explicitly. Instead of using REALM as specified by the --realm option of kcadm.sh config credentials, the command uses TARGET_REALM.

SERVER_URI/admin/realms/TARGET_REALM/ENDPOINT

For example:

$ kcadm.sh config credentials --server http://localhost:8080 --realm master --user 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/admin/realms/demorealm/users.

The create and update commands send a JSON body to the server. You can use -f FILENAME to read a pre-made document from a file. When you can use the -f - option, Red Hat build of Keycloak reads the message body from the standard input. You can specify individual attributes and their values, as seen in the create users example. Red Hat build of Keycloak composes the attributes into a JSON body and sends them to the server.

Several methods are available in Red Hat build of Keycloak to update a resource using the update command. You can determine the current state of a resource and save it to a file, edit that file, and send it to the server for an update.

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 the attributes in the sent JSON document.

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

For example:

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

This method sets the enabled attribute to false.

By default, the update command performs a get and then merges the new attribute values with existing values. 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. Set the attributes to realm and enabled.

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

Red Hat build of Keycloak disables realms by default. You can use a realm immediately for authentication by enabling it.

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

$ kcadm.sh create realms -f demorealm.json

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

For example:

Listing existing realms

This command returns a list of all realms.

$ kcadm.sh get realms

The list of all realm attributes can be verbose, and most users are interested in a subset of attributes, such as the realm name and the enabled status of the realm. You can specify the attributes to return by using the --fields option.

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

You can display the result as comma-separated values.

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

Getting a specific realm

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 that control 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, specifying all event listeners that receive events. Attributes are available that control built-in event storage, so you can query past events using the Admin REST API. Red Hat build of Keycloak has separate control over the logging of service calls (eventsEnabled) and the auditing events triggered by the Admin Console or Admin REST API (adminEventsEnabled). You can set up the eventsExpiration event to expire to prevent your database from filling. Red Hat build of Keycloak sets eventsExpiration to time-to-live expressed in seconds.

You can set up a built-in event listener that receives all events and logs the events through JBoss-logging. Using the org.keycloak.events logger, Red Hat build of Keycloak logs error events as WARN and other events as DEBUG.

For example:

For example:

You can turn on storage for all available ERROR events, not including auditing events, for two days so you can retrieve the events through Admin REST.

You can reset stored event types to all available event types. Setting the value to an empty list is the same as enumerating all.

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

You can enable storage of auditing events.

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

You can get the last 100 events. The events are ordered from newest to oldest.

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

You can 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 a 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 use the get-roles command also.

$ kcadm.sh get-roles -r demorealm

Listing client roles

Red Hat build of Keycloak has a dedicated get-roles command to simplify the listing of realm and client roles. The command is an extension of the get command and behaves the same as the get command but with additional semantics for listing roles.

Use the get-roles command by passing it the clientId (--cclientid) option or the id (--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 existing role’s name.

For example:

$ kcadm.sh get roles/user -r demorealm

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

For example:

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

Getting a specific client role

Use the get-roles command, passing it the clientId attribute (--cclientid option) or ID attribute (--cid option) to identify the client, and pass the role name (--rolename option) or the role ID attribute (--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 endpoint URI 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 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 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 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 the 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 the get-roles command to list assigned, available, and effective client roles for a composite role.

Adding realm roles to a composite role

Red Hat build of Keycloak provides an add-roles command for adding realm roles and client roles.

This 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

Red Hat build of Keycloak provides a remove-roles command for removing 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

Red Hat build of Keycloak provides an add-roles command for adding realm roles and client roles.

The following example adds the roles defined on the client realm-management, create-client, and view-users, 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 the 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, the 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 the add-roles command to add realm roles and client roles.

The following example adds the roles defined on the client realm-management, create-client and view-users, to the Group group (--gname option). Alternatively, you can specify the group by ID (--gid option).

See Group operations for more information.

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

Removing client roles from a group

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

The following example removes two roles defined on the client realm-management, create-client and view-users, from the Group group.

See Group operations for more information.

$ 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.

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

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

Getting a specific client

Use the client 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 the client ID to construct an endpoint URI, such as clients/ID/client-secret.

For example:

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

Generate a new secret for a specific client

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

For example:

$ kcadm.sh create clients/$CID/client-secret -r demorealm

Updating the current secret for a specific client

Use the client ID to construct an endpoint URI, such as clients/ID.

For example:

$ kcadm.sh update clients/$CID -s "secret=newSecret" -r demorealm

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

Use the client 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 the client 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 the client ID to construct an endpoint URI that targets a specific client, such as clients/ID/installation/providers/docker-v2-compose-yaml.

The response is in .zip format.

For example:

$ kcadm.sh get http://localhost:8080/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 use to get a specific client.

For example:

Deleting a client

Use the delete command with the same endpoint URI that you use 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

A client’s service account is a user account with username service-account-CLIENT_ID. You can perform the same user operations on this account as a regular account.

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 must change their 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 q=email:google.com
$ kcadm.sh get users -r demorealm -q q=username:testuser

For clients, groups, and users you can filter across multiple attributes by specifying a more complex q query parameter. you may use something like -q q="field1:value1 field2:value2". Red Hat build of Keycloak returns users that match the condition for all the attributes only.

Getting a specific user

Use the user 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 use to get a specific user.

For example:

Deleting a user

Use the delete command with the same endpoint URI that you use 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

This command sets a temporary password for the user. The target user must change the password the next time they log in.

You can use --userid 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 -n parameter ensures that Red Hat build of Keycloak performs the PUT command without performing a GET command before the PUT command. This is necessary because the reset-password endpoint does not support GET.

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

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

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

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

Adding realm roles to a user

Use an 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 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 an add-roles command to add client roles to a user.

Use the following example to add two roles defined on the client realm-management, the 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 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

Use the 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 use 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 use 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. 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 -s name=SubGroup

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 of a 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 you use 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 the 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 identity provider’s alias attribute 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 use 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 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/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 Stack Overflow 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 hard-coded 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

Obtaining the current password policy

You can get the current realm configuration by filtering all output except for the passwordPolicy attribute.

For example, 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.sh create "authentication/executions/a3147129-c402-4760-86d9-3f2345e401c7/config" -r demorealm -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 demorealm

Updating configuration for an execution

For example:

$ kcadm update "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r demorealm -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 demorealm