7:46 p.m.
In response to Jason's request for design proposals on this list, here
is the proposal for Keycloak SSO in WildFly 9.
Background
-----------------
A major part of our console unification effort is to allow various JBoss
management consoles to take advantage of Single Signon. To achieve this
end, Keycloak SSO[1] will be integrated into the WildFly 9 platform.
The first management consoles to use Keycloak will likely be the WildFly
Web Console[2] and the JON Console.
Proof of Concept
-----------------------
A hacked-up proof of concept is available at
https://github.com/ssilvert/wildfly/tree/kcauth. It demonstrates a
WildFly standalone server using Keycloak for both authentication and
authorization in the Web Console. It also shows single signon between
the Web Console and the Keycloak Admin application. See
https://github.com/ssilvert/wildfly/blob/kcauth/keycloak/KeycloakSetup.txt
for details.
One interesting finding of the POC is that the Keycloak integration
required no changes to the WildFly Web Console. All the integration is
done on the server side and the GWT client works perfectly as-is.
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.
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.
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.
Keycloak Database
--------------------------
The Keycloak database contains all the server-side configuration data
such as the data manipulated by the Keycloak Admin Console. By default,
it is an H2 database that lives in the standalone/data directory. It is
created when the auth server is first deployed.
This database will be initialized with a single "admin" user who has all
rights within the Keycloak Admin Console and within the WildFly Web
Console. On first login, the admin user must change his password.
By default, both consoles will be in the same master realm so that users
can potentially do single signon and move freely between them.
H2 is not recommended for production use. Keycloak has tools available
to migrate data to another database.
Keycloak Adapter
------------------------
A Keycloak adapter is a bit of software that is attached to an
application deployment. This software knows how to talk to the Keycloak
auth server. It handles the OAuth protocol from the client side.
In the case of the WildFly Web Console, the adapter will be a pure
Undertow, non-servlet adapter. The reason for using a pure Undertow
adapter instead of the current Keycloak WildFly adapter is that the
latter adapter relies on the Servlet API, which is forbidden on a domain
controller. The proof of concept mentioned above contains the code
needed for a pure Undertow adapter. This code will likely be migrated
into the Keycloak project.
Keycloak Adapter Configuration
-------------------------------------------
A Keycloak adapter configuration is a json or DMR representation of an
application's client-side Keycloak configuration. It is used by the
adapter to find data such as public keys and the location of the auth
server. (From the POC, see master->Applications->web-console->Installation)
In the case of WildFly Web Console, we actually have two application
endpoints that need to be configured and protected by Keycloak. These
are the GWT-based UI and the http management endpoint that accepts DMR
operations. The Keycloak configuration for these applications will live
in the DMR management tree under SuperUser access. This restrictive
access only applies to the Keycloak adapter configuration. Any RBAC
role can be assigned to a user of the WildFly Web Console via the
Keycloak Admin Console.
Note that the proof of concept still uses json files for the adapter
configuration. The real implementation will need to store the
configuration in the DMR management tree so that it can be maintained by
CLI or the WildFly Web Console.
Questions for further discussion
--------------------------------------------
1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
be available at the realm level or only to the WildFly Web Console?
Could/should other consoles make use of these roles?
2. On first login, you are required to change the admin password. What
other initial setup should be required? Change realm public key?
Change client secret? Others?
3. In the POC, the Keycloak Auth Server WAR is extracted into the
standalone/deployments directory. Are there better options? Should it
even be deployed by default?
4. By default, what Login Options should be enabled for the master
realm? Currently, these options are social login, user registration,
forget password, remember me, verify email, direct grant API, and
require SSL.
5. Should Keycloak audit log be enabled by default? If so, what should
be the expiration value?
6. What should the initial pasword policy be? (length, mixed case,
special chars, etc.)
[1] http://keycloak.jboss.org/
http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/inde...
[2] https://github.com/hal/core
[3]
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_...
8:07 p.m.
On 6/3/2014 1:46 PM, Stan Silvert wrote:
2. On first login, you are required to change the admin password. What
other initial setup should be required? Change realm public key?
Change client secret? Others?
You should be able to self-bootstrap a new install on initial boot. Its
what we do for the Aerogear UPS server.
5. Should Keycloak audit log be enabled by default? If so, what should
be the expiration value?
Not sure. We're relying on tools like fail2ban for brute force
detection at the moment, but hope to get fail2ban like features in
Keycloak after 1.0 is released.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:25 p.m.
On 03/06/14 18:46, Stan Silvert wrote:
In response to Jason's request for design proposals on this list,
here
is the proposal for Keycloak SSO in WildFly 9.
Background
-----------------
A major part of our console unification effort is to allow various JBoss
management consoles to take advantage of Single Signon. To achieve this
end, Keycloak SSO[1] will be integrated into the WildFly 9 platform.
The first management consoles to use Keycloak will likely be the WildFly
Web Console[2] and the JON Console.
Proof of Concept
-----------------------
A hacked-up proof of concept is available at
https://github.com/ssilvert/wildfly/tree/kcauth. It demonstrates a
WildFly standalone server using Keycloak for both authentication and
authorization in the Web Console. It also shows single signon between
the Web Console and the Keycloak Admin application. See
https://github.com/ssilvert/wildfly/blob/kcauth/keycloak/KeycloakSetup.txt
for details.
One interesting finding of the POC is that the Keycloak integration
required no changes to the WildFly Web Console. All the integration is
done on the server side and the GWT client works perfectly as-is.
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.
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. Even then how much does it make sense for each app
server installation to have it's own SSO infrastructure?
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.
Keycloak Database
--------------------------
The Keycloak database contains all the server-side configuration data
such as the data manipulated by the Keycloak Admin Console. By default,
it is an H2 database that lives in the standalone/data directory. It is
created when the auth server is first deployed.
This database will be initialized with a single "admin" user who has all
rights within the Keycloak Admin Console and within the WildFly Web
Console. On first login, the admin user must change his password.
By default, both consoles will be in the same master realm so that users
can potentially do single signon and move freely between them.
H2 is not recommended for production use. Keycloak has tools available
to migrate data to another database.
Keycloak Adapter
------------------------
A Keycloak adapter is a bit of software that is attached to an
application deployment. This software knows how to talk to the Keycloak
auth server. It handles the OAuth protocol from the client side.
In the case of the WildFly Web Console, the adapter will be a pure
Undertow, non-servlet adapter. The reason for using a pure Undertow
adapter instead of the current Keycloak WildFly adapter is that the
latter adapter relies on the Servlet API, which is forbidden on a domain
controller. The proof of concept mentioned above contains the code
needed for a pure Undertow adapter. This code will likely be migrated
into the Keycloak project.
Keycloak Adapter Configuration
-------------------------------------------
A Keycloak adapter configuration is a json or DMR representation of an
application's client-side Keycloak configuration. It is used by the
adapter to find data such as public keys and the location of the auth
server. (From the POC, see master->Applications->web-console->Installation)
In the case of WildFly Web Console, we actually have two application
endpoints that need to be configured and protected by Keycloak. These
are the GWT-based UI and the http management endpoint that accepts DMR
operations. The Keycloak configuration for these applications will live
in the DMR management tree under SuperUser access. This restrictive
access only applies to the Keycloak adapter configuration. Any RBAC
role can be assigned to a user of the WildFly Web Console via the
Keycloak Admin Console.
Note that the proof of concept still uses json files for the adapter
configuration. The real implementation will need to store the
configuration in the DMR management tree so that it can be maintained by
CLI or the WildFly Web Console.
Questions for further discussion
--------------------------------------------
1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
be available at the realm level or only to the WildFly Web Console?
Could/should other consoles make use of these roles?
The direction we are moving towards with the wildfly-elytron work is
that role assignment / mapping is something that happens at the point a
call reaches a secured resource and will be in the context of that
secure resource. As an example a user could call one deployment and be
assigned one set of roles, that same user could call a different
deployment and have a completely different set of roles - for simplicity
we will allow a 1:1 mapping from what was loaded from the identity store
to roles but that will not be always the case.
2. On first login, you are required to change the admin password.
What
other initial setup should be required? Change realm public key?
Change client secret? Others?
This is something that would be required to happen at the command line,
a connection from a web browser could not be trusted to perform this.
3. In the POC, the Keycloak Auth Server WAR is extracted into the
standalone/deployments directory. Are there better options? Should it
even be deployed by default?
As I say above this goes against the current architecture of separating
management from apps.
4. By default, what Login Options should be enabled for the master
realm? Currently, these options are social login, user registration,
forget password, remember me, verify email, direct grant API, and
require SSL.
5. Should Keycloak audit log be enabled by default? If so, what should
be the expiration value?
6. What should the initial pasword policy be? (length, mixed case,
special chars, etc.)
Password policy is warn only for weak passwords, administrators can
override and choose what ever they want.
[1] http://keycloak.jboss.org/
http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/inde...
[2] https://github.com/hal/core
[3]
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_...
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:19 p.m.
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.
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?
> 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.
> Keycloak Database
> --------------------------
> The Keycloak database contains all the server-side configuration data
> such as the data manipulated by the Keycloak Admin Console. By default,
> it is an H2 database that lives in the standalone/data directory. It is
> created when the auth server is first deployed.
>
> This database will be initialized with a single "admin" user who has all
> rights within the Keycloak Admin Console and within the WildFly Web
> Console. On first login, the admin user must change his password.
>
> By default, both consoles will be in the same master realm so that users
> can potentially do single signon and move freely between them.
>
> H2 is not recommended for production use. Keycloak has tools available
> to migrate data to another database.
>
>
> Keycloak Adapter
> ------------------------
> A Keycloak adapter is a bit of software that is attached to an
> application deployment. This software knows how to talk to the Keycloak
> auth server. It handles the OAuth protocol from the client side.
>
> In the case of the WildFly Web Console, the adapter will be a pure
> Undertow, non-servlet adapter. The reason for using a pure Undertow
> adapter instead of the current Keycloak WildFly adapter is that the
> latter adapter relies on the Servlet API, which is forbidden on a domain
> controller. The proof of concept mentioned above contains the code
> needed for a pure Undertow adapter. This code will likely be migrated
> into the Keycloak project.
>
>
> Keycloak Adapter Configuration
> -------------------------------------------
> A Keycloak adapter configuration is a json or DMR representation of an
> application's client-side Keycloak configuration. It is used by the
> adapter to find data such as public keys and the location of the auth
> server. (From the POC, see
master->Applications->web-console->Installation)
>
> In the case of WildFly Web Console, we actually have two application
> endpoints that need to be configured and protected by Keycloak. These
> are the GWT-based UI and the http management endpoint that accepts DMR
> operations. The Keycloak configuration for these applications will live
> in the DMR management tree under SuperUser access. This restrictive
> access only applies to the Keycloak adapter configuration. Any RBAC
> role can be assigned to a user of the WildFly Web Console via the
> Keycloak Admin Console.
>
> Note that the proof of concept still uses json files for the adapter
> configuration. The real implementation will need to store the
> configuration in the DMR management tree so that it can be maintained by
> CLI or the WildFly Web Console.
>
>
> Questions for further discussion
> --------------------------------------------
> 1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
> be available at the realm level or only to the WildFly Web Console?
> Could/should other consoles make use of these roles?
The direction we are moving towards with the wildfly-elytron work is
that role assignment / mapping is something that happens at the point a
call reaches a secured resource and will be in the context of that
secure resource. As an example a user could call one deployment and be
assigned one set of roles, that same user could call a different
deployment and have a completely different set of roles - for simplicity
we will allow a 1:1 mapping from what was loaded from the identity store
to roles but that will not be always the case.
> 2. On first login, you are required to change the admin password. What
> other initial setup should be required? Change realm public key?
> Change client secret? Others?
This is something that would be required to happen at the command line,
a connection from a web browser could not be trusted to perform this.
> 3. In the POC, the Keycloak Auth Server WAR is extracted into the
> standalone/deployments directory. Are there better options? Should it
> even be deployed by default?
As I say above this goes against the current architecture of separating
management from apps.
> 4. By default, what Login Options should be enabled for the master
> realm? Currently, these options are social login, user registration,
> forget password, remember me, verify email, direct grant API, and
> require SSL.
>
> 5. Should Keycloak audit log be enabled by default? If so, what should
> be the expiration value?
>
> 6. What should the initial pasword policy be? (length, mixed case,
> special chars, etc.)
Password policy is warn only for weak passwords, administrators can
override and choose what ever they want.
> [1] http://keycloak.jboss.org/
> http://docs.jboss.org/keycloak/docs/1.0-beta-1/userguide/html_single/inde...
> [2] https://github.com/hal/core
> [3]
> http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_...
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:01 a.m.
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.
>> 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.
4:03 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:46 p.m.
On 04/06/14 15:03, Anil Saldhana wrote:
On 06/04/2014 03:01 AM, Darran Lofthouse wrote:
>
> On 03/06/14 21:19, Stan Silvert wrote:
>> 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.
Sorry you are quite right, what I mean to say was the current app audit
logging is in the container to PicketBox integration points which is an
area that will be re-visited in the wildfly-elytron efforts.
4:50 p.m.
On 06/04/2014 09:46 AM, Darran Lofthouse wrote:
On 04/06/14 15:03, Anil Saldhana wrote:
> On 06/04/2014 03:01 AM, Darran Lofthouse wrote:
>> On 03/06/14 21:19, Stan Silvert wrote:
>>> 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.
Sorry you are quite right, what I mean to say was the current app audit
logging is in the container to PicketBox integration points which is an
area that will be re-visited in the wildfly-elytron efforts.
No apologies
necessary. :-) I think PicketBox has to be respected for all
it does and not completely tie it to JAAS, since that is just an
implementation detail.
I am hoping all the shortcomings we have in PBox to be rectified in
WildFly Elytron.
10:27 p.m.
On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
> 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.
Keycloak uses Resteasy. We could write an adapter for whatever HTTP
engine the mgmt interface is using. Unfortunately, we also need a
storage mechanism JPA or Mongo. We could write a file-based back-end
if needed.
> Questions for further discussion
> --------------------------------------------
> 1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
> be available at the realm level or only to the WildFly Web Console?
> Could/should other consoles make use of these roles?
The direction we are moving towards with the wildfly-elytron work is
that role assignment / mapping is something that happens at the point a
call reaches a secured resource and will be in the context of that
secure resource. As an example a user could call one deployment and be
assigned one set of roles, that same user could call a different
deployment and have a completely different set of roles - for simplicity
we will allow a 1:1 mapping from what was loaded from the identity store
to roles but that will not be always the case.
Keycloak works similarly, albeit with remote invocations. Clients get a
unique token with each application they do SSO with. For nested
invocations, i.e. If you log into Application A and it needs to invoke
on Application B, things can be configured so that the token has all
role mappings that are needed. Each application in the nested call
chain looks inside the token for the role mappings it is interested in.
If there was an adequate SPI, then Keycloak would fit in with this idea
of each deployment call would have its own set of role mappings.
* Keycloak supports realm-level and per-app-level roles.
* Keycloak has the concept of scope mappings. Scopes are the roles the
application is allowed to ask for. So the token is only populated with
permissions the application is allowed to ask for. So, if a user has
"admin" role, the token will not get populated with the "admin" role
mapping unless the application has that scope.
* Keycloak has the concept of a "composite role". Its kinda like a
combination of a role group and a role.
BTW, I think cross-component calls need to be able to inherit the
"identity store" from the calling component. IMO, it would be very
rare (even weird) if cross-component calls each used their own "identity
store".
Currently, Its even more weird (and wrong) that each time you cross a
component layer (deployment) reauthentication happens with the identity
store.
> 2. On first login, you are required to change the admin password. What
> other initial setup should be required? Change realm public key?
> Change client secret? Others?
This is something that would be required to happen at the command line,
a connection from a web browser could not be trusted to perform this.
What if Keycloak out of the box only allowed connections from localhost?
That it would block all other incoming traffic and only allow
connections from 127.0.0.1? Admins would have to remove this restriction.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:37 p.m.
On 06/03/2014 03:27 PM, Bill Burke wrote:
On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
>> 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.
Keycloak uses Resteasy. We could write an adapter for whatever HTTP
engine the mgmt interface is using. Unfortunately, we also need a
storage mechanism JPA or Mongo. We could write a file-based back-end
if needed.
PicketLink IDM default storage is file based. Any opportunity to map
KeyCloak
storage to the IDM API? Last time, Bill told me that he is not very
happy with
the IDM API.
>> Questions for further discussion
>> --------------------------------------------
>> 1. WildFly ships with pre-defined RBAC roles. [3] Should these roles
>> be available at the realm level or only to the WildFly Web Console?
>> Could/should other consoles make use of these roles?
> The direction we are moving towards with the wildfly-elytron work is
> that role assignment / mapping is something that happens at the point a
> call reaches a secured resource and will be in the context of that
> secure resource. As an example a user could call one deployment and be
> assigned one set of roles, that same user could call a different
> deployment and have a completely different set of roles - for simplicity
> we will allow a 1:1 mapping from what was loaded from the identity store
> to roles but that will not be always the case.
Keycloak works similarly, albeit with remote invocations. Clients get a
unique token with each application they do SSO with. For nested
invocations, i.e. If you log into Application A and it needs to invoke
on Application B, things can be configured so that the token has all
role mappings that are needed. Each application in the nested call
chain looks inside the token for the role mappings it is interested in.
If there was an adequate SPI, then Keycloak would fit in with this idea
of each deployment call would have its own set of role mappings.
* Keycloak supports realm-level and per-app-level roles.
* Keycloak has the concept of scope mappings. Scopes are the roles the
application is allowed to ask for. So the token is only populated with
permissions the application is allowed to ask for. So, if a user has
"admin" role, the token will not get populated with the "admin" role
mapping unless the application has that scope.
* Keycloak has the concept of a "composite role". Its kinda like a
combination of a role group and a role.
BTW, I think cross-component calls need to be able to inherit the
"identity store" from the calling component. IMO, it would be very
rare (even weird) if cross-component calls each used their own "identity
store".
Currently, Its even more weird (and wrong) that each time you cross a
component layer (deployment) reauthentication happens with the identity
store.
>> 2. On first login, you are required to change the admin password. What
>> other initial setup should be required? Change realm public key?
>> Change client secret? Others?
> This is something that would be required to happen at the command line,
> a connection from a web browser could not be trusted to perform this.
>
What if Keycloak out of the box only allowed connections from localhost?
That it would block all other incoming traffic and only allow
connections from 127.0.0.1? Admins would have to remove this restriction.
10:50 p.m.
On 6/3/2014 4:37 PM, Anil Saldhana wrote:
On 06/03/2014 03:27 PM, Bill Burke wrote:
>
> On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
>>> 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.
> Keycloak uses Resteasy. We could write an adapter for whatever HTTP
> engine the mgmt interface is using. Unfortunately, we also need a
> storage mechanism JPA or Mongo. We could write a file-based back-end
> if needed.
PicketLink IDM default storage is file based. Any opportunity to map
KeyCloak
storage to the IDM API? Last time, Bill told me that he is not very
happy with
the IDM API.
Keycloak storage has in the past been mapped to the PL IDM API. That
code still exists but is not up to date. We *do* use PL IDM API for
mapping user-data only (not role mappings) to LDAP/AD storage.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:43 p.m.
On 6/3/2014 4:27 PM, Bill Burke wrote:
On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
>> 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.
Keycloak uses Resteasy. We could write an adapter for whatever HTTP
engine the mgmt interface is using. Unfortunately, we also need a
storage mechanism JPA or Mongo. We could write a file-based back-end
if needed.
Most of the config data could be stored in the management model. You
would still need a general storage mechanism for user data, but that
doesn't go against the current design because that is what we have
currently.
I'm interested in opinions about how important it would be to do all that.
10:49 p.m.
On 6/3/2014 4:43 PM, Stan Silvert wrote:
On 6/3/2014 4:27 PM, Bill Burke wrote:
>
> On 6/3/2014 2:25 PM, Darran Lofthouse wrote:
>>> 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.
> Keycloak uses Resteasy. We could write an adapter for whatever HTTP
> engine the mgmt interface is using. Unfortunately, we also need a
> storage mechanism JPA or Mongo. We could write a file-based back-end
> if needed.
Most of the config data could be stored in the management model. You
would still need a general storage mechanism for user data, but that
doesn't go against the current design because that is what we have
currently.
I'm interested in opinions about how important it would be to do all that.
Yeah, we could probably write a management model backend too.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:37 a.m.
On 03/06/14 21:27, Bill Burke wrote:
BTW, I think cross-component calls need to be able to inherit the
"identity store" from the calling component. IMO, it would be very
rare (even weird) if cross-component calls each used their own "identity
store".
Yes that is something we have been discussing on the wildfly-elytron
discussions, the concept that when a call crosses one container to the
next we already have an authenticated identity what we need to be doing
to re mapping the roles so that the role mapping is in the context of
the second component.
Currently, Its even more weird (and wrong) that each time you cross
a
component layer (deployment) reauthentication happens with the identity
store.
As far as I am concerned this is just a side effect of JAAS, as I say
above we will have the need for re analysing the role mapping on the
crossing of containers so that each container sees the correct role
mapping but not this re-authentication.
This in itself however is moving into the teritory of other design
discussions we will be bringing to this list - I just wanted to confirm
that we are moving away from this assumption of a principal and
credential that gets authenticated on each container crossing.
>
>> 2. On first login, you are required to change the admin password. What
>> other initial setup should be required? Change realm public key?
>> Change client secret? Others?
>
> This is something that would be required to happen at the command line,
> a connection from a web browser could not be trusted to perform this.
>
What if Keycloak out of the box only allowed connections from localhost?
That it would block all other incoming traffic and only allow
connections from 127.0.0.1? Admins would have to remove this restriction.
In early AS7 discussions that was deemed insufficient due to privilege
escalation of clients running on the same box, this is the whole reason
the CLI has a local authentication mechanism to verify the user of the
CLI actually has access to the AS installation.
7:23 p.m.
On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
> 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.
Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
My understanding of the original and still current goal of key cloak is to be more of an
appliance, and also largely independent of WildFly.
From that perspective, I don’t think embedding Keycloak solely to be
in the same VM makes a lot of sense (more details as to why follow). It’s fine to have
KeyCloak running on a WildFly instance (either as a subsystem or a deployment), but to me
this seems to be a bit more of a black box to the user.
So a typical topology, based on the factors I am aware of would look like this:
+------+ Auth +----------+
| +----------------> |
| DC | | Keycloak |
+----+ +----+ | |
| +------+ | +----------+
| |
+---v--+ +--v---+
| | | |
| HC | | HC |
+-+ +-+ +-+ +-+
| +--+---+ | | +--+---+ |
| | | | | |
+v-+ +v-+ +-v+ +v-+ +v-+ +-v+
|S1| |S2| |S3| |S4| |S5| |S6|
+--+ +--+ +--+ +--+ +--+ +--+
Each box represents a different JVM running potentially on separate hardware.
So from the architecture the key element we need is for the DC (and standalone server) to
come pre bundled with a client that can talk to the Keycloak blackbox (whether it be
WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH communication.
Now as to why I don’t think embedding as it is makes a lot of sense, is because it
wouldn’t really be a tightly integrated component, but rather two distinct systems duct
taped together. We would have:
1. Multiple distinct management consoles
2. Multiple distinct management APIs
3. Multiple distinct management protocols
4. Multiple distinct CLI/tools
There is of course ways to paper over this and shove them together but you end up with
leaky abstractions. Like lets say the CLI could issue REST operations against Keycloak as
well. Thats great but that means things like the compensating transaction model don’t let
you mix management changes with keycloak changes.
Another issue is that WildFly has some pretty strict backwards compatibility contracts
with regards to management that stem from EAP. Keycloak, at this stage of the process
might not want to put up with us requesting similar conservative governance. It might be
better for us to limit the API dependencies to best enable the project to continue to
evolve.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7:36 p.m.
On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
>> 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.
Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
My understanding of the original and still current goal of key cloak is to be more of an
appliance, and also largely independent of WildFly.
From that perspective, I don’t think embedding Keycloak solely to be in the same VM makes
a lot of sense (more details as to why follow). It’s fine to have KeyCloak running on a
WildFly instance (either as a subsystem or a deployment), but to me this seems to be a bit
more of a black box to the user.
So a typical topology, based on the factors I am aware of would look like this:
+------+ Auth +----------+
| +----------------> |
| DC | | Keycloak |
+----+ +----+ | |
| +------+ | +----------+
| |
+---v--+ +--v---+
| | | |
| HC | | HC |
+-+ +-+ +-+ +-+
| +--+---+ | | +--+---+ |
| | | | | |
+v-+ +v-+ +-v+ +v-+ +v-+ +-v+
|S1| |S2| |S3| |S4| |S5| |S6|
+--+ +--+ +--+ +--+ +--+ +--+
Actually it should look like this, if you factor in deployments doing auth as
well.
+------+ Auth +----------+
| +----------------> |
| DC | | Keycloak |
+----+ +----+ | |
| +------+ | +-----^----+
| | |
+---v--+ +--v---+ |
| | | | |
| HC | | HC | | Application Auth
+-+ +-+ +-+ +-+ |
| +--+---+ | | +--+---+ | |
| | | | | | |
+v-+ +v-+ +-v+ +v-+ +v-+ +-v+ |
|S1| |S2| |S3| |S4| |S5| |S6|----------+
+--+ +--+ +--+ +--+ +--+ +--+
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7:48 p.m.
On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
There is of course ways to paper over this and shove them together
but you end up with leaky abstractions. Like lets say the CLI could issue REST operations
against Keycloak as well. Thats great but that means things like the compensating
transaction model don’t let you mix management changes with keycloak changes.
Another issue is that WildFly has some pretty strict backwards compatibility contracts
with regards to management that stem from EAP. Keycloak, at this stage of the process
might not want to put up with us requesting similar conservative governance. It might be
better for us to limit the API dependencies to best enable the project to continue to
evolve.
Other problems I forgot to mention (oops sorry!)
1. Lifecycle robustness problems - Management is not supposed to affect applications, so
if the user takes down or moves the DC it would take down application auth as well - Bad!
2. Chicken-egg problems in standalone mode - subsystems aren’t started when the server is
in admin-only mode. (Although this one is solvable)
3. Lots of additional work.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:25 p.m.
On 6/4/14, 12:48 PM, Jason Greene wrote:
On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
> There is of course ways to paper over this and shove them together but you end up
with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>
> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
Other problems I forgot to mention (oops sorry!)
1. Lifecycle robustness problems - Management is not supposed to affect applications, so
if the user takes down or moves the DC it would take down application auth as well - Bad!
2. Chicken-egg problems in standalone mode - subsystems aren’t started when the server is
in admin-only mode. (Although this one is solvable)
Subsystem services aren't started only because operation handlers by
default don't do runtime stuff in admin-only mode. But a subsystem
author could certainly have their handlers do stuff in admin-only if it
was appropriate.
Your comment however makes me realize a flaw in how I'd been seeing
this, where the Keycloak server could simply be an application running
on one of the servers in the domain. But servers are under the control
of an HC, and an HC in admin-only will not launch servers. So there's a
chicken-egg issue there.
3. Lots of additional work.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:32 p.m.
On 6/4/2014 1:23 PM, Jason Greene wrote:
On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
>> 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.
Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
My understanding of the original and still current goal of key cloak is to be more of an
appliance, and also largely independent of WildFly.
From that perspective, I don’t think embedding Keycloak solely to be in the same VM
makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak running
on a WildFly instance (either as a subsystem or a deployment), but to me this seems to be
a bit more of a black box to the user.
So a typical topology, based on the factors I am aware of would look like this:
+------+ Auth +----------+
| +----------------> |
| DC | | Keycloak |
+----+ +----+ | |
| +------+ | +----------+
| |
+---v--+ +--v---+
| | | |
| HC | | HC |
+-+ +-+ +-+ +-+
| +--+---+ | | +--+---+ |
| | | | | |
+v-+ +v-+ +-v+ +v-+ +v-+ +-v+
|S1| |S2| |S3| |S4| |S5| |S6|
+--+ +--+ +--+ +--+ +--+ +--+
Each box represents a different JVM running potentially on separate hardware.
So from the architecture the key element we need is for the DC (and standalone server) to
come pre bundled with a client that can talk to the Keycloak blackbox (whether it be
WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH communication.
Now as to why I don’t think embedding as it is makes a lot of sense, is because it
wouldn’t really be a tightly integrated component, but rather two distinct systems duct
taped together. We would have:
1. Multiple distinct management consoles
2. Multiple distinct management APIs
3. Multiple distinct management protocols
4. Multiple distinct CLI/tools
There is of course ways to paper over this and shove them together but you end up with
leaky abstractions. Like lets say the CLI could issue REST operations against Keycloak as
well. Thats great but that means things like the compensating transaction model don’t let
you mix management changes with keycloak changes.
Another issue is that WildFly has some pretty strict backwards compatibility contracts
with regards to management that stem from EAP. Keycloak, at this stage of the process
might not want to put up with us requesting similar conservative governance. It might be
better for us to limit the API dependencies to best enable the project to continue to
evolve.
Jason,
I think we should first get Keycloak to secure Wildfly in standalone
mode or with a domain controller. In both cases the Wildfly console
should be securable by Keycloak. I'm betting that a lot of these issues
will flesh out and become much clearer on how to solve.
Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
is a very important use case for us to be able to be embbeded and to
secure Wildfly and to manage security for Wildfly.
We have already learned a lot by being embedded with Aerogear UPS as
their security console and solution. For example, keycloak now has
pluggable themes/skins themes/skins for its entire UI: admin console,
login pages, etc. This has allowed Keycloak to be branded as an
Aerogear subsystem and it looks like one product.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:05 p.m.
On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
On 6/4/2014 1:23 PM, Jason Greene wrote:
>
> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
>
>>> 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.
>
> Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
>
> My understanding of the original and still current goal of key cloak is to be more of
an appliance, and also largely independent of WildFly.
>
> From that perspective, I don’t think embedding Keycloak solely to be in the same VM
makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak running
on a WildFly instance (either as a subsystem or a deployment), but to me this seems to be
a bit more of a black box to the user.
>
> So a typical topology, based on the factors I am aware of would look like this:
>
>
>
> +------+ Auth +----------+
> | +----------------> |
> | DC | | Keycloak |
> +----+ +----+ | |
> | +------+ | +----------+
> | |
> +---v--+ +--v---+
> | | | |
> | HC | | HC |
> +-+ +-+ +-+ +-+
> | +--+---+ | | +--+---+ |
> | | | | | |
> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
> |S1| |S2| |S3| |S4| |S5| |S6|
> +--+ +--+ +--+ +--+ +--+ +--+
>
>
> Each box represents a different JVM running potentially on separate hardware.
>
> So from the architecture the key element we need is for the DC (and standalone
server) to come pre bundled with a client that can talk to the Keycloak blackbox (whether
it be WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH
communication.
>
> Now as to why I don’t think embedding as it is makes a lot of sense, is because it
wouldn’t really be a tightly integrated component, but rather two distinct systems duct
taped together. We would have:
>
> 1. Multiple distinct management consoles
> 2. Multiple distinct management APIs
> 3. Multiple distinct management protocols
> 4. Multiple distinct CLI/tools
>
> There is of course ways to paper over this and shove them together but you end up
with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>
> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
>
Jason,
I think we should first get Keycloak to secure Wildfly in standalone
mode or with a domain controller. In both cases the Wildfly console
should be securable by Keycloak. I'm betting that a lot of these issues
will flesh out and become much clearer on how to solve.
Certainly agree there.
Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
is a very important use case for us to be able to be embbeded and to
secure Wildfly and to manage security for Wildfly.
We have already learned a lot by being embedded with Aerogear UPS as
their security console and solution. For example, keycloak now has
pluggable themes/skins themes/skins for its entire UI: admin console,
login pages, etc. This has allowed Keycloak to be branded as an
Aerogear subsystem and it looks like one product.
I don’t think anyone has veto’d anything. I have just highlighted the challenges. They
aren’t insurmountable but they would require some effort to solve. We could for example
have management operation wrappers which trigger the appropriate actions in key cloak, and
this could solve the CLI problems I mentioned, and allow for the admin console to do cross
system interactions. Some of the other issues I don’t have a clear idea on, but some
thinking might come up with something.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10:45 a.m.
On 04/06/14 22:05, Jason Greene wrote:
On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 6/4/2014 1:23 PM, Jason Greene wrote:
>>
>> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
>>
>>>> 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.
>>
>> Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
>>
>> My understanding of the original and still current goal of key cloak is to be
more of an appliance, and also largely independent of WildFly.
>>
>> From that perspective, I don’t think embedding Keycloak solely to be in the same
VM makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak
running on a WildFly instance (either as a subsystem or a deployment), but to me this
seems to be a bit more of a black box to the user.
>>
>> So a typical topology, based on the factors I am aware of would look like this:
>>
>>
>>
>> +------+ Auth +----------+
>> | +----------------> |
>> | DC | | Keycloak |
>> +----+ +----+ | |
>> | +------+ | +----------+
>> | |
>> +---v--+ +--v---+
>> | | | |
>> | HC | | HC |
>> +-+ +-+ +-+ +-+
>> | +--+---+ | | +--+---+ |
>> | | | | | |
>> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
>> |S1| |S2| |S3| |S4| |S5| |S6|
>> +--+ +--+ +--+ +--+ +--+ +--+
>>
>>
>> Each box represents a different JVM running potentially on separate hardware.
>>
>> So from the architecture the key element we need is for the DC (and standalone
server) to come pre bundled with a client that can talk to the Keycloak blackbox (whether
it be WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH
communication.
>>
>> Now as to why I don’t think embedding as it is makes a lot of sense, is because
it wouldn’t really be a tightly integrated component, but rather two distinct systems duct
taped together. We would have:
>>
>> 1. Multiple distinct management consoles
>> 2. Multiple distinct management APIs
>> 3. Multiple distinct management protocols
>> 4. Multiple distinct CLI/tools
>>
>> There is of course ways to paper over this and shove them together but you end up
with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>>
>> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
>>
>
> Jason,
>
> I think we should first get Keycloak to secure Wildfly in standalone
> mode or with a domain controller. In both cases the Wildfly console
> should be securable by Keycloak. I'm betting that a lot of these issues
> will flesh out and become much clearer on how to solve.
Certainly agree there.
+1 This is what I was trying to say in a reply to Stan earlier, getting
to the point where we can enable keycloak based authentication for the
http management interface in standalone mode and in domain mode sounds
like the ideal starting point.
For one in itself it is a complete deliverable task that provides a
complete set of functionality and it completely removes any obstacle
from those that wish to use KeyCloak instead of the standard HTTP
mechanisms.
As a second task we can then review how a default bundling with KeyCloak
could be provided either enabled by default or enableable - but
hopefully you can see from some of the messages here providing the
complete solution has a lot of issues that need to be resolved.
>
> Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
> is a very important use case for us to be able to be embbeded and to
> secure Wildfly and to manage security for Wildfly.
>
> We have already learned a lot by being embedded with Aerogear UPS as
> their security console and solution. For example, keycloak now has
> pluggable themes/skins themes/skins for its entire UI: admin console,
> login pages, etc. This has allowed Keycloak to be branded as an
> Aerogear subsystem and it looks like one product.
I don’t think anyone has veto’d anything. I have just highlighted the challenges. They
aren’t insurmountable but they would require some effort to solve. We could for example
have management operation wrappers which trigger the appropriate actions in key cloak, and
this could solve the CLI problems I mentioned, and allow for the admin console to do cross
system interactions. Some of the other issues I don’t have a clear idea on, but some
thinking might come up with something.
Please don't feel like anything is bein veto'd - if we were vetoing
anything we would be coming back with lines like project elytron is well
underway, you are going to be interfacing with existing implementations
that we know are changing, discussing KeyCloak today is a time drain
etc....
Personally I want to see KeyCloak in for authentication as soon as
possible, it is going to be representative of the approaches we must be
able to support with the wildfly-elytron work and as Stan says having a
testable existing implementation to compare against will provide us a
lot of benefits in this area.
But for the complete solution I think we have a lot more issues to
solve, the application server development has progressed a long way
since we effectively just had a standalone mode server - everything we
do we now need to consider both standalone mode and domain mode. We
have also had a lot of input from the security response team and the
current design constraints we operate in for our out of the box offering
is based on a lot of discussion with them as well as other interested
parties focussed on the developer experience.
One other aspect I experience when it comes to security is if you take
the simple problem first and solve that adding a solution for the
complex problem becomes much harder. And then finally lets say we add a
full standalone solution to the WildFly codebase today and leave domain
mode to be handled second, we risk reaching a point if domain mode is
not ready that either Jason has to release an app server with domain
mode behaving differently to standalone mode or the release has to be
held up.
So my preference here is we identify the task that we can deliver in
it's entirety and look at getting authentication working for both
standalone and domain mode and then look at the default inclusion as a
second step. This will give use something that can be documented, used,
demoed, blogged about etc... The second stage would then be removing
some of the manual installation tasks a user would need to perform but
in the first stage we would have reached the major milestone of KeyCloak
being usable for authentication when managing WildFly.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:01 p.m.
I'm back from PTO now. Thanks to everyone for the excellent feedback.
It sounds like the one thing we have broad agreement on is that we
should at least ship the Keycloak adapters with WildFly. That way, the
Web Console and other client apps can use Keycloak as their auth server
if they want.
I like Darran's suggestion to go ahead and integrate the adapters as a
first task. It should keep me busy for awhile. We can keep thinking
about Keycloak auth server integration in the mean time.
So now with a narrower focus, I still have one problem. What are the
requirements of a domain controller using Keycloak? More specifically,
is it a requirement to be able to log into Web Console when the DC is
the only thing running?
I ask because if Web Console on DC is secured with Keycloak and it can't
reach the Keycloak auth server then you can't log in. Maybe we already
have this problem? Is it ever the case that the Web Console
authenticates against an LDAP server? If so then you have the same
problem if it can't reach the LDAP server.
Stan
On 6/5/2014 4:45 AM, Darran Lofthouse wrote:
On 04/06/14 22:05, Jason Greene wrote:
> On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
>
>>
>> On 6/4/2014 1:23 PM, Jason Greene wrote:
>>> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
>>>
>>>>> 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.
>>> Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
>>>
>>> My understanding of the original and still current goal of key cloak is to be
more of an appliance, and also largely independent of WildFly.
>>>
>>> From that perspective, I don’t think embedding Keycloak solely to be in the
same VM makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak
running on a WildFly instance (either as a subsystem or a deployment), but to me this
seems to be a bit more of a black box to the user.
>>>
>>> So a typical topology, based on the factors I am aware of would look like
this:
>>>
>>>
>>>
>>> +------+ Auth +----------+
>>> | +----------------> |
>>> | DC | | Keycloak |
>>> +----+ +----+ | |
>>> | +------+ | +----------+
>>> | |
>>> +---v--+ +--v---+
>>> | | | |
>>> | HC | | HC |
>>> +-+ +-+ +-+ +-+
>>> | +--+---+ | | +--+---+ |
>>> | | | | | |
>>> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
>>> |S1| |S2| |S3| |S4| |S5| |S6|
>>> +--+ +--+ +--+ +--+ +--+ +--+
>>>
>>>
>>> Each box represents a different JVM running potentially on separate
hardware.
>>>
>>> So from the architecture the key element we need is for the DC (and
standalone server) to come pre bundled with a client that can talk to the Keycloak
blackbox (whether it be WildFly or fat jar or whatever). I assume this mostly amounts to
OAUTH communication.
>>>
>>> Now as to why I don’t think embedding as it is makes a lot of sense, is
because it wouldn’t really be a tightly integrated component, but rather two distinct
systems duct taped together. We would have:
>>>
>>> 1. Multiple distinct management consoles
>>> 2. Multiple distinct management APIs
>>> 3. Multiple distinct management protocols
>>> 4. Multiple distinct CLI/tools
>>>
>>> There is of course ways to paper over this and shove them together but you
end up with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>>>
>>> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
>>>
>> Jason,
>>
>> I think we should first get Keycloak to secure Wildfly in standalone
>> mode or with a domain controller. In both cases the Wildfly console
>> should be securable by Keycloak. I'm betting that a lot of these issues
>> will flesh out and become much clearer on how to solve.
> Certainly agree there.
+1 This is what I was trying to say in a reply to Stan earlier, getting
to the point where we can enable keycloak based authentication for the
http management interface in standalone mode and in domain mode sounds
like the ideal starting point.
For one in itself it is a complete deliverable task that provides a
complete set of functionality and it completely removes any obstacle
from those that wish to use KeyCloak instead of the standard HTTP
mechanisms.
As a second task we can then review how a default bundling with KeyCloak
could be provided either enabled by default or enableable - but
hopefully you can see from some of the messages here providing the
complete solution has a lot of issues that need to be resolved.
>> Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
>> is a very important use case for us to be able to be embbeded and to
>> secure Wildfly and to manage security for Wildfly.
>>
>> We have already learned a lot by being embedded with Aerogear UPS as
>> their security console and solution. For example, keycloak now has
>> pluggable themes/skins themes/skins for its entire UI: admin console,
>> login pages, etc. This has allowed Keycloak to be branded as an
>> Aerogear subsystem and it looks like one product.
> I don’t think anyone has veto’d anything. I have just highlighted the challenges.
They aren’t insurmountable but they would require some effort to solve. We could for
example have management operation wrappers which trigger the appropriate actions in key
cloak, and this could solve the CLI problems I mentioned, and allow for the admin console
to do cross system interactions. Some of the other issues I don’t have a clear idea on,
but some thinking might come up with something.
Please don't feel like anything is bein veto'd - if we were vetoing
anything we would be coming back with lines like project elytron is well
underway, you are going to be interfacing with existing implementations
that we know are changing, discussing KeyCloak today is a time drain
etc....
Personally I want to see KeyCloak in for authentication as soon as
possible, it is going to be representative of the approaches we must be
able to support with the wildfly-elytron work and as Stan says having a
testable existing implementation to compare against will provide us a
lot of benefits in this area.
But for the complete solution I think we have a lot more issues to
solve, the application server development has progressed a long way
since we effectively just had a standalone mode server - everything we
do we now need to consider both standalone mode and domain mode. We
have also had a lot of input from the security response team and the
current design constraints we operate in for our out of the box offering
is based on a lot of discussion with them as well as other interested
parties focussed on the developer experience.
One other aspect I experience when it comes to security is if you take
the simple problem first and solve that adding a solution for the
complex problem becomes much harder. And then finally lets say we add a
full standalone solution to the WildFly codebase today and leave domain
mode to be handled second, we risk reaching a point if domain mode is
not ready that either Jason has to release an app server with domain
mode behaving differently to standalone mode or the release has to be
held up.
So my preference here is we identify the task that we can deliver in
it's entirety and look at getting authentication working for both
standalone and domain mode and then look at the default inclusion as a
second step. This will give use something that can be documented, used,
demoed, blogged about etc... The second stage would then be removing
some of the manual installation tasks a user would need to perform but
in the first stage we would have reached the major milestone of KeyCloak
being usable for authentication when managing WildFly.
>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:15 p.m.
In that case yes they do need to be able to log into the admin console
on a DC that is not running any servers, as you say if the LDAP server
is down they can not connect (except by using local auth if enabled) -
but in this case is there anything stopping them installing keycloak on
a completely independent wildfly installation?
i.e. the security infrastructure is independent from the app server
installation it is securing.
Regards,
Darran Lofthouse.
On 05/06/14 19:01, Stan Silvert wrote:
I'm back from PTO now. Thanks to everyone for the excellent
feedback.
It sounds like the one thing we have broad agreement on is that we
should at least ship the Keycloak adapters with WildFly. That way, the
Web Console and other client apps can use Keycloak as their auth server
if they want.
I like Darran's suggestion to go ahead and integrate the adapters as a
first task. It should keep me busy for awhile. We can keep thinking
about Keycloak auth server integration in the mean time.
So now with a narrower focus, I still have one problem. What are the
requirements of a domain controller using Keycloak? More specifically,
is it a requirement to be able to log into Web Console when the DC is
the only thing running?
I ask because if Web Console on DC is secured with Keycloak and it can't
reach the Keycloak auth server then you can't log in. Maybe we already
have this problem? Is it ever the case that the Web Console
authenticates against an LDAP server? If so then you have the same
problem if it can't reach the LDAP server.
Stan
On 6/5/2014 4:45 AM, Darran Lofthouse wrote:
>
> On 04/06/14 22:05, Jason Greene wrote:
>> On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>
>>>
>>> On 6/4/2014 1:23 PM, Jason Greene wrote:
>>>> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
>>>>
>>>>>> 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.
>>>> Sorry for my delayed reply. I hadn’t had a chance to read the full
thread.
>>>>
>>>> My understanding of the original and still current goal of key cloak is
to be more of an appliance, and also largely independent of WildFly.
>>>>
>>>> From that perspective, I don’t think embedding Keycloak solely to be
in the same VM makes a lot of sense (more details as to why follow). It’s fine to have
KeyCloak running on a WildFly instance (either as a subsystem or a deployment), but to me
this seems to be a bit more of a black box to the user.
>>>>
>>>> So a typical topology, based on the factors I am aware of would look like
this:
>>>>
>>>>
>>>>
>>>> +------+ Auth +----------+
>>>> | +----------------> |
>>>> | DC | | Keycloak |
>>>> +----+ +----+ | |
>>>> | +------+ | +----------+
>>>> | |
>>>> +---v--+ +--v---+
>>>> | | | |
>>>> | HC | | HC |
>>>> +-+ +-+ +-+ +-+
>>>> | +--+---+ | | +--+---+ |
>>>> | | | | | |
>>>> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
>>>> |S1| |S2| |S3| |S4| |S5| |S6|
>>>> +--+ +--+ +--+ +--+ +--+ +--+
>>>>
>>>>
>>>> Each box represents a different JVM running potentially on separate
hardware.
>>>>
>>>> So from the architecture the key element we need is for the DC (and
standalone server) to come pre bundled with a client that can talk to the Keycloak
blackbox (whether it be WildFly or fat jar or whatever). I assume this mostly amounts to
OAUTH communication.
>>>>
>>>> Now as to why I don’t think embedding as it is makes a lot of sense, is
because it wouldn’t really be a tightly integrated component, but rather two distinct
systems duct taped together. We would have:
>>>>
>>>> 1. Multiple distinct management consoles
>>>> 2. Multiple distinct management APIs
>>>> 3. Multiple distinct management protocols
>>>> 4. Multiple distinct CLI/tools
>>>>
>>>> There is of course ways to paper over this and shove them together but
you end up with leaky abstractions. Like lets say the CLI could issue REST operations
against Keycloak as well. Thats great but that means things like the compensating
transaction model don’t let you mix management changes with keycloak changes.
>>>>
>>>> Another issue is that WildFly has some pretty strict backwards
compatibility contracts with regards to management that stem from EAP. Keycloak, at this
stage of the process might not want to put up with us requesting similar conservative
governance. It might be better for us to limit the API dependencies to best enable the
project to continue to evolve.
>>>>
>>> Jason,
>>>
>>> I think we should first get Keycloak to secure Wildfly in standalone
>>> mode or with a domain controller. In both cases the Wildfly console
>>> should be securable by Keycloak. I'm betting that a lot of these issues
>>> will flesh out and become much clearer on how to solve.
>> Certainly agree there.
> +1 This is what I was trying to say in a reply to Stan earlier, getting
> to the point where we can enable keycloak based authentication for the
> http management interface in standalone mode and in domain mode sounds
> like the ideal starting point.
>
> For one in itself it is a complete deliverable task that provides a
> complete set of functionality and it completely removes any obstacle
> from those that wish to use KeyCloak instead of the standard HTTP
> mechanisms.
>
> As a second task we can then review how a default bundling with KeyCloak
> could be provided either enabled by default or enableable - but
> hopefully you can see from some of the messages here providing the
> complete solution has a lot of issues that need to be resolved.
>
>>> Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
>>> is a very important use case for us to be able to be embbeded and to
>>> secure Wildfly and to manage security for Wildfly.
>>>
>>> We have already learned a lot by being embedded with Aerogear UPS as
>>> their security console and solution. For example, keycloak now has
>>> pluggable themes/skins themes/skins for its entire UI: admin console,
>>> login pages, etc. This has allowed Keycloak to be branded as an
>>> Aerogear subsystem and it looks like one product.
>> I don’t think anyone has veto’d anything. I have just highlighted the challenges.
They aren’t insurmountable but they would require some effort to solve. We could for
example have management operation wrappers which trigger the appropriate actions in key
cloak, and this could solve the CLI problems I mentioned, and allow for the admin console
to do cross system interactions. Some of the other issues I don’t have a clear idea on,
but some thinking might come up with something.
> Please don't feel like anything is bein veto'd - if we were vetoing
> anything we would be coming back with lines like project elytron is well
> underway, you are going to be interfacing with existing implementations
> that we know are changing, discussing KeyCloak today is a time drain
> etc....
>
> Personally I want to see KeyCloak in for authentication as soon as
> possible, it is going to be representative of the approaches we must be
> able to support with the wildfly-elytron work and as Stan says having a
> testable existing implementation to compare against will provide us a
> lot of benefits in this area.
>
> But for the complete solution I think we have a lot more issues to
> solve, the application server development has progressed a long way
> since we effectively just had a standalone mode server - everything we
> do we now need to consider both standalone mode and domain mode. We
> have also had a lot of input from the security response team and the
> current design constraints we operate in for our out of the box offering
> is based on a lot of discussion with them as well as other interested
> parties focussed on the developer experience.
>
> One other aspect I experience when it comes to security is if you take
> the simple problem first and solve that adding a solution for the
> complex problem becomes much harder. And then finally lets say we add a
> full standalone solution to the WildFly codebase today and leave domain
> mode to be handled second, we risk reaching a point if domain mode is
> not ready that either Jason has to release an app server with domain
> mode behaving differently to standalone mode or the release has to be
> held up.
>
> So my preference here is we identify the task that we can deliver in
> it's entirety and look at getting authentication working for both
> standalone and domain mode and then look at the default inclusion as a
> second step. This will give use something that can be documented, used,
> demoed, blogged about etc... The second stage would then be removing
> some of the manual installation tasks a user would need to perform but
> in the first stage we would have reached the major milestone of KeyCloak
> being usable for authentication when managing WildFly.
>
>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:21 p.m.
On 6/5/2014 2:15 PM, Darran Lofthouse wrote:
i.e. the security infrastructure is independent from the app server
installation it is securing.
I think that answers my question. Sounds like this is
a non-issue.
Regards,
Darran Lofthouse.
On 05/06/14 19:01, Stan Silvert wrote:
> I'm back from PTO now. Thanks to everyone for the excellent feedback.
>
> It sounds like the one thing we have broad agreement on is that we
> should at least ship the Keycloak adapters with WildFly. That way, the
> Web Console and other client apps can use Keycloak as their auth server
> if they want.
>
> I like Darran's suggestion to go ahead and integrate the adapters as a
> first task. It should keep me busy for awhile. We can keep thinking
> about Keycloak auth server integration in the mean time.
>
> So now with a narrower focus, I still have one problem. What are the
> requirements of a domain controller using Keycloak? More specifically,
> is it a requirement to be able to log into Web Console when the DC is
> the only thing running?
>
> I ask because if Web Console on DC is secured with Keycloak and it can't
> reach the Keycloak auth server then you can't log in. Maybe we already
> have this problem? Is it ever the case that the Web Console
> authenticates against an LDAP server? If so then you have the same
> problem if it can't reach the LDAP server.
>
> Stan
>
>
> On 6/5/2014 4:45 AM, Darran Lofthouse wrote:
>> On 04/06/14 22:05, Jason Greene wrote:
>>> On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>>
>>>> On 6/4/2014 1:23 PM, Jason Greene wrote:
>>>>> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
>>>>>
>>>>>>> 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.
>>>>> Sorry for my delayed reply. I hadn’t had a chance to read the full
thread.
>>>>>
>>>>> My understanding of the original and still current goal of key cloak
is to be more of an appliance, and also largely independent of WildFly.
>>>>>
>>>>> From that perspective, I don’t think embedding Keycloak solely to
be in the same VM makes a lot of sense (more details as to why follow). It’s fine to have
KeyCloak running on a WildFly instance (either as a subsystem or a deployment), but to me
this seems to be a bit more of a black box to the user.
>>>>>
>>>>> So a typical topology, based on the factors I am aware of would look
like this:
>>>>>
>>>>>
>>>>>
>>>>> +------+ Auth +----------+
>>>>> | +----------------> |
>>>>> | DC | | Keycloak |
>>>>> +----+ +----+ | |
>>>>> | +------+ | +----------+
>>>>> | |
>>>>> +---v--+ +--v---+
>>>>> | | | |
>>>>> | HC | | HC |
>>>>> +-+ +-+ +-+ +-+
>>>>> | +--+---+ | | +--+---+ |
>>>>> | | | | | |
>>>>> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
>>>>> |S1| |S2| |S3| |S4| |S5| |S6|
>>>>> +--+ +--+ +--+ +--+ +--+ +--+
>>>>>
>>>>>
>>>>> Each box represents a different JVM running potentially on separate
hardware.
>>>>>
>>>>> So from the architecture the key element we need is for the DC (and
standalone server) to come pre bundled with a client that can talk to the Keycloak
blackbox (whether it be WildFly or fat jar or whatever). I assume this mostly amounts to
OAUTH communication.
>>>>>
>>>>> Now as to why I don’t think embedding as it is makes a lot of sense,
is because it wouldn’t really be a tightly integrated component, but rather two distinct
systems duct taped together. We would have:
>>>>>
>>>>> 1. Multiple distinct management consoles
>>>>> 2. Multiple distinct management APIs
>>>>> 3. Multiple distinct management protocols
>>>>> 4. Multiple distinct CLI/tools
>>>>>
>>>>> There is of course ways to paper over this and shove them together
but you end up with leaky abstractions. Like lets say the CLI could issue REST operations
against Keycloak as well. Thats great but that means things like the compensating
transaction model don’t let you mix management changes with keycloak changes.
>>>>>
>>>>> Another issue is that WildFly has some pretty strict backwards
compatibility contracts with regards to management that stem from EAP. Keycloak, at this
stage of the process might not want to put up with us requesting similar conservative
governance. It might be better for us to limit the API dependencies to best enable the
project to continue to evolve.
>>>>>
>>>> Jason,
>>>>
>>>> I think we should first get Keycloak to secure Wildfly in standalone
>>>> mode or with a domain controller. In both cases the Wildfly console
>>>> should be securable by Keycloak. I'm betting that a lot of these
issues
>>>> will flesh out and become much clearer on how to solve.
>>> Certainly agree there.
>> +1 This is what I was trying to say in a reply to Stan earlier, getting
>> to the point where we can enable keycloak based authentication for the
>> http management interface in standalone mode and in domain mode sounds
>> like the ideal starting point.
>>
>> For one in itself it is a complete deliverable task that provides a
>> complete set of functionality and it completely removes any obstacle
>> from those that wish to use KeyCloak instead of the standard HTTP
>> mechanisms.
>>
>> As a second task we can then review how a default bundling with KeyCloak
>> could be provided either enabled by default or enableable - but
>> hopefully you can see from some of the messages here providing the
>> complete solution has a lot of issues that need to be resolved.
>>
>>>> Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
>>>> is a very important use case for us to be able to be embbeded and to
>>>> secure Wildfly and to manage security for Wildfly.
>>>>
>>>> We have already learned a lot by being embedded with Aerogear UPS as
>>>> their security console and solution. For example, keycloak now has
>>>> pluggable themes/skins themes/skins for its entire UI: admin console,
>>>> login pages, etc. This has allowed Keycloak to be branded as an
>>>> Aerogear subsystem and it looks like one product.
>>> I don’t think anyone has veto’d anything. I have just highlighted the
challenges. They aren’t insurmountable but they would require some effort to solve. We
could for example have management operation wrappers which trigger the appropriate actions
in key cloak, and this could solve the CLI problems I mentioned, and allow for the admin
console to do cross system interactions. Some of the other issues I don’t have a clear
idea on, but some thinking might come up with something.
>> Please don't feel like anything is bein veto'd - if we were vetoing
>> anything we would be coming back with lines like project elytron is well
>> underway, you are going to be interfacing with existing implementations
>> that we know are changing, discussing KeyCloak today is a time drain
>> etc....
>>
>> Personally I want to see KeyCloak in for authentication as soon as
>> possible, it is going to be representative of the approaches we must be
>> able to support with the wildfly-elytron work and as Stan says having a
>> testable existing implementation to compare against will provide us a
>> lot of benefits in this area.
>>
>> But for the complete solution I think we have a lot more issues to
>> solve, the application server development has progressed a long way
>> since we effectively just had a standalone mode server - everything we
>> do we now need to consider both standalone mode and domain mode. We
>> have also had a lot of input from the security response team and the
>> current design constraints we operate in for our out of the box offering
>> is based on a lot of discussion with them as well as other interested
>> parties focussed on the developer experience.
>>
>> One other aspect I experience when it comes to security is if you take
>> the simple problem first and solve that adding a solution for the
>> complex problem becomes much harder. And then finally lets say we add a
>> full standalone solution to the WildFly codebase today and leave domain
>> mode to be handled second, we risk reaching a point if domain mode is
>> not ready that either Jason has to release an app server with domain
>> mode behaving differently to standalone mode or the release has to be
>> held up.
>>
>> So my preference here is we identify the task that we can deliver in
>> it's entirety and look at getting authentication working for both
>> standalone and domain mode and then look at the default inclusion as a
>> second step. This will give use something that can be documented, used,
>> demoed, blogged about etc... The second stage would then be removing
>> some of the manual installation tasks a user would need to perform but
>> in the first stage we would have reached the major milestone of KeyCloak
>> being usable for authentication when managing WildFly.
>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:05 p.m.
On Jun 4, 2014, at 2:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
On 6/4/2014 1:23 PM, Jason Greene wrote:
>
> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
>
>>> 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.
>
> Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
>
> My understanding of the original and still current goal of key cloak is to be more of
an appliance, and also largely independent of WildFly.
>
> From that perspective, I don’t think embedding Keycloak solely to be in the same VM
makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak running
on a WildFly instance (either as a subsystem or a deployment), but to me this seems to be
a bit more of a black box to the user.
>
> So a typical topology, based on the factors I am aware of would look like this:
>
>
>
> +------+ Auth +----------+
> | +----------------> |
> | DC | | Keycloak |
> +----+ +----+ | |
> | +------+ | +----------+
> | |
> +---v--+ +--v---+
> | | | |
> | HC | | HC |
> +-+ +-+ +-+ +-+
> | +--+---+ | | +--+---+ |
> | | | | | |
> +v-+ +v-+ +-v+ +v-+ +v-+ +-v+
> |S1| |S2| |S3| |S4| |S5| |S6|
> +--+ +--+ +--+ +--+ +--+ +--+
>
>
> Each box represents a different JVM running potentially on separate hardware.
>
> So from the architecture the key element we need is for the DC (and standalone
server) to come pre bundled with a client that can talk to the Keycloak blackbox (whether
it be WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH
communication.
>
> Now as to why I don’t think embedding as it is makes a lot of sense, is because it
wouldn’t really be a tightly integrated component, but rather two distinct systems duct
taped together. We would have:
>
> 1. Multiple distinct management consoles
> 2. Multiple distinct management APIs
> 3. Multiple distinct management protocols
> 4. Multiple distinct CLI/tools
>
> There is of course ways to paper over this and shove them together but you end up
with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>
> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
>
Jason,
I think we should first get Keycloak to secure Wildfly in standalone
mode or with a domain controller. In both cases the Wildfly console
should be securable by Keycloak. I'm betting that a lot of these issues
will flesh out and become much clearer on how to solve.
Certainly agree there.
Irregardless of the Wildfly team vetoing the inclusion of keycloak, it
is a very important use case for us to be able to be embbeded and to
secure Wildfly and to manage security for Wildfly.
We have already learned a lot by being embedded with Aerogear UPS as
their security console and solution. For example, keycloak now has
pluggable themes/skins themes/skins for its entire UI: admin console,
login pages, etc. This has allowed Keycloak to be branded as an
Aerogear subsystem and it looks like one product.
I don’t think anyone has veto’d anything. I have just highlighted the challenges. They
aren’t insurmountable but they would require some effort to solve. We could for example
have management operation wrappers which trigger the appropriate actions in key cloak, and
this could solve the CLI problems I mentioned, and allow for the admin console to do cross
system interactions. Some of the other issues I don’t have a clear idea on, but some
thinking might come up with something.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3612
days inactive
3614
days old
24 comments
6 participants
participants (6)
-
Anil Saldhana -
Bill Burke -
Brian Stansberry -
Darran Lofthouse -
Jason Greene -
Stan Silvert