[keycloak-dev] Brining KeyCloak to WildFly Management / Subsystemless Integration

Bill Burke bburke at redhat.com
Fri Jan 31 09:51:33 EST 2014


What I think needs to be done is figure out how exactly you want 
bootstrapping and configuration to look like.  What are the user facing 
interactions?  What GUI or CLI commands need to be done?  What can we do 
to provide an integrated, simple, easy to use, nice SSO solution for 
Wildfly?

As for Keycloak: CORS, switching IPs, Integrating with existing auth 
mechs, and OAuth are all things we do or want to do.  You have to 
remember though that Keycloak is a solution.  A user-facing solution. 
If you're only interested in adapters to integrate Wildfly with some 
third-party SAML, oauth, openid, or whatever solution, then Keycloak is 
not for you.  We're not an third-party adapter provider.  I'm really not 
interested in Keycloak becoming another Picketlink where we provide a 
set of libraries to help you build your own security solution.

But, if you're interested in focusing on providing an OOTB SSO solution 
for Wildfly, then we can talk:

For a CORS solution, we only have "validated CORS" where the allowed 
origins are stuffed in the signed token you get from the auth server. 
There will probably be a few cases where users want unauthenticated CORS 
invocations.  Implementation wise, much of the CORS stuff is broken out 
into different Undertow handlers.  I also think Undertow has some of 
this too (all the preflight stuff).

Using different IPs (i.e. LDAP/AD) is on the back burner for at least a 
few months as we focus on Wildfly integration, themes, and other 
critical features.

What do you mean by Enabling OAuth?  If this means just having Wildfly 
participate as an OAuth client, then again Keycloak is not for you.  If 
you want Wildfly to be the OAuth provider, then, you would need 
something like keycloak in order to provide login screens and grant pages.

For Keycloak integrating with other auth mechanisms, I see this as a 
Keycloak problem in that we need to be able to work with clients that we 
cannot install an adapter on, but yet support a protocol like SAML.

On 1/31/2014 7:26 AM, Darran Lofthouse wrote:
> Hi all,
>
> Just finishing off some WildFly 8 tasks and have a few things to work on
> for EAP after that but as soon as that is done I need to get on with the
> next steps for WildFly 9.
>
> For the future SSO within domain management we have a few different
> issues to content with: -
>    - CORS
>    - Switching to a new identity provider
>    - Integrating with existing authentication mechanisms
>    - Enabling OAuth
>
> What I wanted to check with you guys before I start raising some
> tracking issues is if we can consider these points independently or if
> we are going to need an all at once approach?
>
> As an example we had a discussion the other day where it was identified
> there may already be a CORS implementation in KeyCloak we can use, that
> is also one of our number one requirements in WildFly - would it be an
> option to integrate that portion first and then start looking to the rest?
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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


More information about the keycloak-dev mailing list