sync with latest changes
This commit is contained in:
--add
parent
49916ca536
commit
cc4654922e
6 changed files with 8 additions and 60 deletions
|
|
@ -22,51 +22,7 @@ What is supported for Fuse is:
|
|||
Basically all mentioned web applications require to inject {{book.project.name}} Jetty authenticator into underlying Jetty server . The steps to achieve it are bit different
|
||||
according to application type. The details are described in individual sub-chapters.
|
||||
|
||||
<<<<<<< HEAD
|
||||
===== Builtin CXF web applications
|
||||
|
||||
Some services automatically come with deployed servlets on startup. One of such examples is CXF servlet running on
|
||||
http://localhost:8181/cxf context. Securing such endpoints is quite tricky. The approach, which Keycloak is currently using,
|
||||
is providing ServletReregistrationService, which undeploys builtin servlet at startup, so you are able to re-deploy it again on context secured by Keycloak.
|
||||
You can see the `OSGI-INF/blueprint/blueprint.xml` inside `cxf-jaxrs` example, which adds JAX-RS `customerservice` endpoint and more importantly, it secures whole `/cxf` context.
|
||||
|
||||
As a side effect, all other CXF services running on default CXF HTTP destination will be secured too. Once you uninstall feature `keycloak-fuse-6.2-example`, the
|
||||
original unsecured servlet on `/cxf` context is deployed back and hence context will become unsecured again.
|
||||
|
||||
It's recommended to use your own Jetty engine for your apps (similarly like `cxf-jaxws` application is doing).
|
||||
|
||||
|
||||
==== How to secure Fuse admin services
|
||||
|
||||
===== SSH authentication to Fuse terminal with Keycloak credentials
|
||||
|
||||
Keycloak mainly addresses usecases for authentication of web applications, however if your admin services (like fuse admin console) are protected
|
||||
with Keycloak, it may be good to protect non-web services like SSH with Keycloak credentials too. It's possible to do it by using JAAS login module, which
|
||||
allows to remotely connect to Keycloak and verify credentials based on
|
||||
|
||||
// <<_direct_access_grants,Direct Access Grants>> .
|
||||
|
||||
Example steps for enable SSH authentication require changing the configuration of `sshRealm` in `$FUSE_HOME/etc/org.apache.karaf.shell.cfg`, then adding
|
||||
file `$FUSE_HOME/etc/keycloak-direct-access.json` (this is default location, which can be changed) and install the needed feature `keycloak-jaas`. It's described in details
|
||||
in the README file of Fuse example, which in example distribution is inside `fuse/fuse-admin/README.md` .
|
||||
|
||||
|
||||
===== JMX authentication with Keycloak credentials
|
||||
|
||||
This may be needed in case if you really want to use jconsole or other external tool to perform remote connection to JMX through RMI. Otherwise it may
|
||||
be better to use just hawt.io/jolokia as jolokia agent is installed in http://hawt.io by default.
|
||||
|
||||
You need to configure `jmxRealm` in `$FUSE_HOME/etc/org.apache.karaf.management.cfg`, then adding file `$FUSE_HOME/etc/keycloak-direct-access.json`
|
||||
(this is default location, which can be changed) and install the needed feature `keycloak-jaas`.
|
||||
It's described in details in the README file of Fuse example, which in example distribution is inside `fuse/fuse-admin/README.md` .
|
||||
|
||||
|
||||
===== Secure Fuse admin console
|
||||
|
||||
Fuse admin console is Hawt.io. See http://hawt.io/configuration/index.html[Hawt.io documentation] for more info about how to secure it with Keycloak.
|
||||
=======
|
||||
{% if book.community %}
|
||||
The best place to start is look at Fuse demo bundled as part of {{book.project.name}} examples in directory `fuse` . Most of the steps should be understandable from testing and
|
||||
understanding the demo.
|
||||
{% endif %}
|
||||
>>>>>>> 163974a212546af0df02970a57466a056b83ba5a
|
||||
|
|
|
|||
|
|
@ -174,10 +174,8 @@ public class CustomerService {
|
|||
This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
|
||||
|
||||
The first thing you must do is create a `keycloak.json` adapter config file within the `WEB-INF` directory of your WAR.
|
||||
|
||||
The format of this config file is describe in the <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>> section.
|
||||
|
||||
|
||||
Next you must set the `auth-method` to `KEYCLOAK` in `web.xml`.
|
||||
You also have to use standard servlet security to specify role-base constraints on your URLs.
|
||||
|
||||
|
|
@ -261,9 +259,7 @@ This metadata is instead defined within server configuration (i.e. `standalone.x
|
|||
|
||||
The `secure-deployment` `name` attribute identifies the WAR you want to secure.
|
||||
Its value is the `module-name` defined in `web.xml` with `.war` appended.
|
||||
|
||||
The rest of the configuration corresponds pretty much one to one with the `keycloak.json` configuration options defined in <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>>.
|
||||
|
||||
The exception is the `credential` element.
|
||||
|
||||
To make it easier for you, you can go to the {{book.project.title}} Administration Console and go to the Application/Installation tab of the application this WAR is aligned with.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
[[_jetty9_adapter]]
|
||||
=== Jetty 9.x Adapters
|
||||
|
||||
|
|
@ -5,7 +6,7 @@ Keycloak has a separate adapter for Jetty 9.1.x and Jetty 9.2.x that you will ha
|
|||
You then have to provide some extra configuration in each WAR you deploy to Jetty.
|
||||
Let's go over these steps.
|
||||
|
||||
[[_jetty-9_adapter_installation]]
|
||||
[[_jetty9_adapter_installation]]
|
||||
==== Adapter Installation
|
||||
|
||||
Adapters are no longer included with the appliance or war distribution.Each adapter is a separate download on the Keycloak download site.
|
||||
|
|
@ -57,10 +58,8 @@ This is a Jetty specific config file and you must define a Keycloak specific aut
|
|||
----
|
||||
|
||||
Next you must create a `keycloak.json` adapter config file within the `WEB-INF` directory of your WAR.
|
||||
|
||||
The format of this config file is describe in the <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>> section.
|
||||
|
||||
|
||||
WARNING: The Jetty 9.1.x adapter will not be able to find the `keycloak.json` file.
|
||||
You will have to define all adapter settings within the `jetty-web.xml` file as described below.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,10 +45,8 @@ This is a Tomcat specific config file and you must define a Keycloak specific Va
|
|||
----
|
||||
|
||||
Next you must create a `keycloak.json` adapter config file within the `WEB-INF` directory of your WAR.
|
||||
|
||||
The format of this config file is describe in the <<fake/../java-adapter-config.adoc#_java_adapter_config,Java adapter configuration>> section.
|
||||
|
||||
|
||||
Finally you must specify both a `login-config` and use standard servlet security to specify role-base constraints on your URLs.
|
||||
Here's an example:
|
||||
|
||||
|
|
|
|||
|
|
@ -118,6 +118,7 @@ browser history. This is somewhat mitigated by using short expiration for Access
|
|||
|
||||
For more details refer to the http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit Flow] in the OpenID Connect specification.
|
||||
|
||||
[[_resource_owner_password_credentials_flow]]
|
||||
==== Resource Owner Password Credentials
|
||||
|
||||
Resource Owner Password Credentials, referred to as Direct Grant in {{book.project.name}}, allows exchanging user credentials for tokens. It's not recommended
|
||||
|
|
|
|||
|
|
@ -2,5 +2,3 @@
|
|||
|
||||
This section describes how you can secure applications and services with OpenID Connect using either {{book.project.name}} adapters or generic OpenID Connect
|
||||
Resource Provider libraries.
|
||||
|
||||
// TODO: Update the cross-reference <<_direct_access_grants,Direct Access Grants>> in the topic /oidc/java/fuse-adapter.adoc
|
||||
|
|
|
|||
Loading…
Reference in a new issue