[wildfly-dev] System deployments? WAS: Creating a Keycloak Feature Pack

[Stan Silvert]

On 9/11/2014 2:31 PM, Brian Stansberry wrote:
> On 9/11/14, 12:20 PM, Stan Silvert wrote:
>> On 9/10/2014 5:24 PM, Brian Stansberry wrote:
>>> On 9/10/14, 1:47 PM, Stan Silvert wrote:
>>>
>>>> *Issue #3: Adding a deployment:*  The Keycloak auth server is deployed
>>>> as a WAR.  We can use the copy-artifacts mechanism to simply copy the
>>>> WAR into the deployments directory.  But that doesn't work for a domain
>>>> where you want to have the WAR pre-loaded into the content repository.
>>>> Furthermore, it's probably not the best way to integrate this for
>>>> standalone either.
>>>>
>>>> What would be a better option?
>>>>
>>> See the "A Mixed Approach" section at
>>> https://developer.jboss.org/docs/DOC-25627
>>>
>>> The two comments at the bottom of that page are also relevant to that
>>> part of the wiki.
>>>
>>> Cheers,
>>>
>> Awesome.  That actually solves several potential problems.  Thanks Brian.
>>
> You're welcome.
>
> The drawback I mentioned there is these deployments appear in the
> resource tree alongside the regular user deployments. That's not ideal,
> because things can happen like the user undeploying or removing the
> deployment, plus it just mixes things that are somewhat separate.
That's OK for now.  Still a big improvement over copying to the 
/deployments directory.
>
> We've briefly discussed in the past the idea of having a
> "system-deployment" tree that looks just like the "deployment" tree
> except the registration of the handlers for the "add", "remove" "deploy"
> "undeploy" ops would have a flag added that marks them as private, so
> they don't show up in the public API. They can still be invoked
> internally by subsystem though.
+1  This might be especially important for Keycloak.  You would want to 
limit the damage an attacker could do if he gained access to DMR but not 
to Keycloak itself.  You don't want the attacker to be able to deploy 
his own auth server in place of the real one.  Same goes for the 
Keycloak datasource and the Keycloak subsystem.
>
> The change to that "fibo" example in the wiki would be minimal.
>
> This would impact the console's "Runtime" tab, as it's another tree of
> runtime data to present. Also, these deployments wouldn't appear in the
> Content Repository tab, which in general is good, although there may be
> some subtle UX effects.
>
> It would also change the location in the tree at which these things
> appear from EAP 6.x to EAP 7.x, but I don't think that's a big deal.
>
> What do folks think about pursuing this? Mazz, your opinion would be useful.
>
> Cheers,
>