Re: [keycloak-dev] subsystem integration phase 1
On 2/6/2014 8:01 AM, ssilvert(a)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