[keycloak-dev] Keycloak Subsystem PR

[Bill Burke]

I wasn't asking to change it, just figuring out the scope of work.  For 
integration, I want the keycloak admin console to remotely manipulate 
the Keycloak subsystem.  If it is always DIGEST (or something that 
Apache Client can handle automatically via a challenge), then I don't 
have to worry about things.

On 1/30/2014 10:23 AM, Darran Lofthouse wrote:
> No at the moment it is not possible to override the mechanism unless you
> switch to LDAP or JAAS for authentication.
>
> We could add a config option to force it to BASIC but with the ongoing
> changes planned it is probably not worth it.
>
> On 30/01/14 15:18, Bill Burke wrote:
>> Awesome stan!  After I get composite roles in, I'll take a look and make
>> improvements where I can.
>>
>> BTW, do you know if the remote admin REST api is only authenticated via
>> DIGEST?  Can it be configured to use other options?
>>
>> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>>> I've done the initial pull request for the Keycloak subsystem.  After
>>> starting fresh with the latest build I was finally able to verify  that
>>> it really does work end to end!
>>>
>>> I probably won't have much more time to work on Keycloak for the next
>>> 4-5 weeks.  So I'll try to put everything I know about it into these
>>> notes in case someone wants to take it over.  I happy to answer
>>> questions though.
>>>
>>> Directions to try the subsystem on your own:
>>> * Build the new subsystem module.
>>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>>> to use the subsystem, so you will need to use WildFly.
>>> * Update standalone.xml.  I've attached a version of standalone.xml that
>>> I used with the Keycloak appliance.  It shows adding the Keycloak
>>> extension near the top of the file and adding the subsystem definition
>>> near the bottom.
>>> * Copy
>>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>> * Copy
>>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>>> to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>> * Edit module.xml and add the subsystem jar as a resource-root.
>>> Alternatively, you can just use the module.xml attached to this email.
>>> * Copy
>>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>>> to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>>
>>> Now if you reboot WildFly you can view and manipulate the subsystem
>>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>>> should be working.  I recommend CLI GUI so you can see everything in
>>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>>
>>> To test the subsystem with a live application, I did the following:
>>> * Copy the customer-portal.war to customer-portal-subsys.war.
>>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>>> The subsystem makes those files redundant.
>>> * Edit the web.xml inside the WAR and change the <module-name> to
>>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>>> need to manipulate web.xml settings at deploy time then the subsystem
>>> can be modified to do that too.
>>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>>> should have the same settings as customer-portal.
>>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>>
>>> Future tasks for the Keycloak Subsystem:
>>> * Integration with the Keycloak Admin
>>> * Review the attributes of realm and secure-deployment to make sure they
>>> align with keycloak.json.
>>> * Fill in help text in
>>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>>> * See comments in KeycloakAdapterConfigService.java.  This class may
>>> work better as a plain Singleton instead of a service.
>>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>>> subsystem a quick review.
>>> * More tests
>>> * Package the subsystem with the distribution
>>> * Documentation
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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