I've been giving some thought to the Keycloak integration with WildFly CLI. There are two designs. Both involve a subsystem called "kcrest" with a resource called "server". You can define a server to talk to using these three attributes:
base-url ( value is something like http://localhost:8080/auth/admin/realms)
username
password

username and password are optional. If you don't mind having these values stored in standalone.xml/domain.xml you can specify them. That way, you don't have to include them with each request.

Design #1: Implement all of the Keycloak REST API in CLI
We build out resources for each REST path and put them in the management model. Then build out operations for everything. So a CLI session to create a client called "myclient" might look like this:
cd /subsystem=kcrest/server=foo
cd realm=myrealm
clients=myclient:add(enabled=true)

Design #2: Create a single generic operation that closely mimics the REST API
cd /subsystem=kcrest/server=foo
:submit(method=POST, path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"})

Advantages of Design #1

Looks and behaves just like other CLI resources
Uses standard CLI operations
Each resource and operation can contain help text
Everything can be navigated from CLI command line or CLI GUI tree, making it easy to browse the model

Disadvantages of Design #1

It might take a very long time to implement (2-3 months?)
Ongoing maintenance. Every time REST API changes, you have to update subsystem code

Advantages of Design #2

Quick to implement (2-3 weeks)
Always works despite REST API changes

Disadvantages of Design #2

:submit operations get long and ugly
Can't specify help text for each resource
Hard to browse the model. Need to submit "list" style REST invocations.

Note that it might be possible to auto-generate Design #1. If so, it would be the best of both worlds.

Whoever implements this should probably start with Design #2 and then spend some time researching auto-generation of Design #1.

Other thoughts?