[keycloak-dev] subsystem integration phase 1
ssilvert at redhat.com
ssilvert at redhat.com
Thu Feb 6 12:04:26 EST 2014
On 2/6/2014 10:22 AM, Bill Burke wrote:
> On 2/6/2014 10:12 AM, ssilvert at redhat.com wrote:
>> On 2/6/2014 9:45 AM, Bill Burke wrote:
>>> 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.
>> That's the thing. You shouldn't need a login-config if you are using
>> the Keycloak subsystem.
> But you need security constraints :)
Exactly. Role-related stuff only. You shouldn't need login-config.
>>>> 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.
More information about the keycloak-dev