[keycloak-dev] subsystem integration phase 1
bburke at redhat.com
Thu Feb 6 09:45:43 EST 2014
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
> 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.
JBoss, a division of Red Hat
More information about the keycloak-dev