[keycloak-dev] subsystem integration phase 1

[Bill Burke]

On 2/6/2014 8:01 AM, ssilvert at redhat.com wrote:
>
> 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.
>

This isn't a big deal if you have enabled login-config.  I'm pretty sure 
it defaults to "other" which defaults to the application*.properties 
files (which are empty by default).  So you wouldn't be able to use the 
application anyways.

> 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.

Not sure I like the idea of deploying apps through Keycloak, although it 
would probably be really easy to implement it.  I think we need to 
define the preferred ways we want this to work.

It might be like this:

Scenario 1:  There is no existing keycloak app

1. Deploy the app to wildfly instance
2. Go to Keycloak Realm
3. Click a "Import Application" button on Application page
4. specify URL of wildfly instance and deployment name (and credentials)
5. Suck up role definitions from Wildfly instance
6. push back to instance a client id and secret, realm information, etc.

Scenario 2: There is an existing app

1. Go to Keycloak Realm
2. Go to Application page
3. Go to Installation page
4. Specify URL of wildfly instance and deployment name (and creds)
5. Push to the client id and secret and realm info to the wildfly instance.

What sucks implementation wise is that we have to have a Wildfly plugin 
on the Keycloak server.  Would be cool if we could define a common REST 
API for this.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com