<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">BTW, I've got some down time waiting on
Elytron, so I've decided to do a quickie implementation of #2 to
see how it goes.<br>
<br>
On 5/15/2015 8:36 AM, Stan Silvert wrote:<br>
</div>
<blockquote cite="mid:5555E867.4020703@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>