[keycloak-dev] subsystem integration phase 1

Bill Burke bburke at redhat.com
Thu Feb 6 10:22:17 EST 2014



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 :)

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


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


More information about the keycloak-dev mailing list