From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Thursday, 6 February, 2014 2:19:04 AM Subject: [keycloak-dev] subsystem integration phase 1 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. Creating a realm if it doesn't already exist, then creating the deployment. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Wed, 05 Feb 2014 21:19:04 -0500 Bill Burke <bburke(a)redhat.com&gt; 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?

_______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

On 2/6/2014 10:12 AM, ssilvert(a)redhat.com wrote: > On 2/6/2014 9:45 AM, Bill Burke wrote: >> 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. > That's the thing. You shouldn't need a login-config if you are using > the Keycloak subsystem. But you need security constraints :)

>>> 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. > Yes, it's easy to implement. I've already done it twice for web console > and CLI GUI. I still think it's a cleaner, safer way to do it. But > it's also something we don't need right away. We need to support your > two scenarios anyway. >> 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. >> > Do you mean a plugin for the Keycloak Admin? You are saying that it > would be nice if we could do the equivalent of a subsystem on other app > servers and have a common API to talk to it? common REST API that all app server's use. We would write those adapters, but the admin console just talks through the common REST API.