[wildfly-dev] Keycloak SSO in WildFly 9

[Anil Saldhana]

On 06/04/2014 03:01 AM, Darran Lofthouse wrote:
>
> On 03/06/14 21:19, Stan Silvert wrote:
>> On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
>>> On 03/06/14 18:46, Stan Silvert wrote:
>>>> Relation to the Elytron and other WildFly 9 changes
>>>> ------------------------------------------------------------------------
>>>> Keycloak is expected to use Elytron at a low level.  Nothing at the
>>>> Keycloak integration level should be affected by the Elytron project.
>>>>
>>>> However, there are many other expected changes to security that may
>>>> effect how Keycloak is integrated.  It is likely that the initial
>>>> integration of Keycloak will happen before these aforementioned
>>>> changes.  This will be an advantage as the unit tests for Keycloak
>>>> integration can help to validate these changes.
>>> One important change we will need to get in first is the splitting of
>>> the contexts that server the management requests, the existing
>>> /management context needs to remain supporting the existing
>>> authentication mechanisms with cross origin restrictions left on.
>> This will be fine.  There is presently no reliance on CORS.
>>>> Default Authentication Mechanism
>>>> ------------------------------------------------
>>>> Keycloak is a very new technology.  Given that security is so vital, we
>>>> need time for Keycloak to mature.  When Keycloak is first integrated, it
>>>> will not be the default authentication/authorization mechanism for the
>>>> WildFly Web Console.  However, selecting Keycloak for authentication
>>>> should be as simple as executing one or two CLI commands.
>>>>
>>>> We can switch to Keycloak as the default whenever we all believe that
>>>> both Keycloak itself and its integration into WildFly are ready for
>>>> prime time.  Hopefully, that will just be a matter of months after first
>>>> integration.
>>> We also need to have the SSL out of the box or as soon as possible after
>>> problem solved.
>> +1
>>> Even then how much does it make sense for each app
>>> server installation to have it's own SSO infrastructure?
>> It's important to at least have it available as an option to turn on.
> That part I am fine with, out biggest concern is the WildFly
> distribution needs to be fully functional out of the box which means for
> KeyCloak to be used by default we need everything in that single instance.
>
> On the other hand, here are the steps you need to go through including
> how to set up your SSO infrastructure and cross reference it from the
> WildFly configuration is fine.  Even installing it as a war on a WildFly
> installation in this context is fine as by then you have reached a point
> where the purpose of that installation is to host KeyCloak.
>
> If I am reading your results from the POC correctly this may be the best
> way to go anyway to get a standalone and domain mode solution available
> simultaneously - packaging and distribution options for a complete
> solution could be a second step.
>
> One point while I think of it - we will need the native management
> interface to be secured by the same identity store and make sure the
> existing http mechanisms can use the same store, if that has not already
> been considered that may be a higher priority.
>
>> In production, the SSO infrastructure wouldn't be live on every instance.
>>
>> Also, Keycloak is much more than just SSO infrastructure.  Other
>> features like user management, password management, auditing, skinning,
>> and the nice UI make it an excellent choice for applications that don't
>> require SSO.   Who wants to keep coding all that stuff by hand?
> Auditing I am deliberately ignoring other than to say that is going to
> be a big topic in itself ;-)  We already have two auditing solutions in
> WildFly one purely for management, the other for apps - the app auditing
> is tied very closely to the JAAS integration so we know something will
> happen in that area.  From the perspective of wildfly-elytron we haven't
> reviewed auditing yet as it should not be driving the security solution.
The App auditing is not tied to JAAS. It is done in the EJB and Web security
integration. I am tired of people just equating what we have to JAAS. JAAS
is an implementation detail.

>
>>>> Initial Integration
>>>> ------------------------
>>>> The initial integration for most of Keycloak will only be available on
>>>> standalone.  However, on a domain controller, the WildFly Web Console
>>>> will still be able to use Keycloak for authentication and
>>>> authorization.  In this case,  the domain controller must be able to
>>>> reach a Keycloak Authentication Server somewhere on the network.
>>>>
>>>>
>>>> Keycloak Authentication Server and Admin Console
>>>> -----------------------------------------------------------------------
>>>> The Keycloak Authentication Server is responsible for authenticating and
>>>> authorizing users.  The Keycloak Admin Console is an AngularJS UI that
>>>> administrators use to manage users, roles, sessions, passwords, assigned
>>>> applications, etc.
>>>>
>>>> Both the auth server and admin console are served from the same WAR.  It
>>>> should be possible to deploy this without using a WAR or servlets, but
>>>> that is not planned for the initial WildFly integration.  Because of
>>>> this current limitation, the auth server and admin console will not be
>>>> present in a domain controller.
>>> This is going against the current design of AS7/WildFly exposing
>>> management related operations over the management interface and leaving
>>> the web container to be purely about a users deployments.
>> The auth server and admin console don't necessarily need to be deployed
>> as a WAR.  It's an AngularJS app, so we could make it work exactly the
>> same way the web console does.  There is also a middle ground where
>> don't expose the fact that it's a WAR.  I think JON does something like
>> that?
>>
>> This is a big discussion we will need to have.
> +1 As I say above it may be better to first reach the point where a
> WildFly instance can be configured to use an existing KeyCloak
> installation in standalone and domain mode (and with the native
> interface and standard http mechanisms) and then address the how to
> bring the rest of KeyCloak in as a second step.
>
> Finding a way to bring it all in would be a pre-requisite for an out of
> the box solution, we also have other items to bring up again soon such
> as continuing with out of the box authentication not dependent on SSL
> (although this has it's own issues if content in the management model is
> sensitive).
>
> But as I understand some of the demand for this the first major problem
> is there is no way for users to even enable this form of SSO so getting
> the first step enabled would be a major step forward.
>
> One point to clarify (not saying anyone is saying this but just to be
> clear) - I don't see us reaching a point where we say KeyCloak is
> exclusively the only authentication approach we will support for
> management, we have legacy client support requirements and end users
> will also have their own set of preferred solution.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev