[keycloak-dev] subsystem integration phase 1

[ssilvert at redhat.com]

On 2/6/2014 6:50 AM, Karel Piwko wrote:
> On Wed, 05 Feb 2014 21:19:04 -0500
> Bill Burke <bburke at redhat.com> wrote:
>
>> Going to iterate on this.  The admin console UI could end up different 
>> in the end, but for phase 1 this is what I've decided to do:
>>
>> * Get rid of RequiredApplicationCredentials.  Applications will have a 
>> viewable client secret from admin console.  This will be resetable form 
>> admin console too.  (cloud.google.com allows you to view the client secret)
>> * Application Install page will now just have a select list.  Options 
>> will be: "config file", "remote wildfly".  Basically all integration 
>> points we support.
>> * "config file" will display what we have now, except credential will be 
>> set up as client secret will be exposed
>> * "remote wildfly" will bring you to a page that asks for:
>>
>> - URL of Wildfly admin
>> - username and password of wildfly instance
>> - deployment name
>> - A "Configure" button
>>
>> Clicking the configure button will remotely set up the wildfly 
>> subsystem.  
> Sounds great.
>
>> Creating a realm if it doesn't already exist, then creating 
>> the deployment.
>>
> What is meant by deployment here? User will provide a WAR/EAR that we be
> remotely deployed?
He means the association of the deployment with the realm.  A realm can
have zero or more secure-deployment resources.  The name of the
secure-deployment maps to a deployment name in WildFly.

At deploy time, the keycloak subsystem checks to see if the deployment
name matches a secure-deployment defined in the subsystem.  If so, it
adds all the keycloak goodness.

This does bring up one possible usability issue.  If you intend for your
deployment to be managed by the keycloak subsystem then you don't want
to deploy it until you have defined it in the subsystem.  So the
workflow is like this:

1) Define the secure-deployment in the keycloak subsystem.
2) Deploy the application on WildFly

The problem here in step 1 is that there is no way to pick the
deployment from a list in Keycloak admin.  You just have to know what
name it will be deployed under before you deploy.  That's not a big
problem, but it's not ideal.

Alternatively, you could do this:
1) Deploy the application in a disabled state.  This is allowed in both
CLI and web console, but it is not the default.
2) Define the secure-deployment in the keycloak subsystem.
3) Enable the deployment.

The problem with this is that because disabled is not the default, the
application is likely to be deployed in an unsecure state for some
period of time.

Ideally, you could deploy the application from Keycloak admin.  It would
automatically deploy in a disabled state and then enable the application
when security setup is complete.  IMO, deployment from Keycloak should
become the preferred deployment method in production systems.  It would
be a lot cleaner than what admins are faced with today.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev