<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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:<br>
base-url ( value is something like
<a class="moz-txt-link-freetext" href="http://localhost:8080/auth/admin/realms">http://localhost:8080/auth/admin/realms</a>)<br>
username<br>
password<br>
<br>
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.<br>
<br>
<b>Design #1: Implement all of the Keycloak REST API in CLI<br>
</b>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:<br>
cd /subsystem=kcrest/server=foo<br>
cd realm=myrealm<br>
clients=myclient:add(enabled=true)<br>
<br>
<b>Design #2: Create a single generic operation that closely mimics
the REST API</b><br>
cd /subsystem=kcrest/server=foo<br>
:submit(method=POST,
path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"})<br>
<b><br>
</b><b>Advantages of Design #1</b><br>
<ul>
<li>Looks and behaves just like other CLI resources</li>
<li>Uses standard CLI operations</li>
<li>Each resource and operation can contain help text</li>
<li>Everything can be navigated from CLI command line or CLI GUI
tree, making it easy to browse the model<br>
</li>
</ul>
<p><b>Disadvantages of Design #1</b><b><br>
</b></p>
<ul>
<li>It might take a very long time to implement (2-3 months?)<br>
</li>
<li>Ongoing maintenance. Every time REST API changes, you have to
update subsystem code</li>
</ul>
<p><b>Advantages of Design #2<br>
</b></p>
<ul>
<li>Quick to implement (2-3 weeks)</li>
<li>Always works despite REST API changes</li>
</ul>
<p><b>Disadvantages of Design #2<br>
</b></p>
<ul>
<li>:submit operations get long and ugly</li>
<li>Can't specify help text for each resource</li>
<li>Hard to browse the model. Need to submit "list" style REST
invocations.</li>
</ul>
<p>Note that it might be possible to auto-generate Design #1. If
so, it would be the best of both worlds.<br>
</p>
<p>Whoever implements this should probably start with Design #2 and
then spend some time researching auto-generation of Design #1.<br>
</p>
<p>Other thoughts?<br>
</p>
</body>
</html>