3:51 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com