[keycloak-dev] Keycloak Subsystem PR

[Darran Lofthouse]

Ah Ok, I misunderstood - often when people ask to change it it is 
because they are trying to eliminate the challenge and force it down to 
BASIC auth ;-)

At this stage the management interface on WildFly supports Basic 
authentication, Digest authentication, or Client Cert authentication - 
the motivation here being use standard mechanisms and standard libraries 
will be able to use them.  We may also add SPNEGO to this list.

Longer term whatever happens with new capabilities e.g. enabling SSO the 
/management context will always be able to have these mechanisms enabled 
and a new context /management2 (Name TBC) will be added for the new 
mechanism(s).

Regards,
Darran Lofthouse.


On 30/01/14 15:34, Bill Burke wrote:
> 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
>>
>