[keycloak-dev] subsystem integration phase 1

[ssilvert at redhat.com]

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