Fix typos in Securing Apps
This commit is contained in:
Kohei Tamura
parent
b46cbadbd0
commit
252bf71768
18 changed files with 28 additions and 28 deletions
|
|
@ -5,7 +5,7 @@ NOTE: Docker authentication is disabled by default. To enable see link:{installg
|
|||
|
||||
This section describes how you can configure a Docker registry to use {project_name} as its authentication server.
|
||||
|
||||
Fore more information on how to set up and configure a Docker registry, see the link:https://docs.docker.com/registry/configuration/[Docker Registry Configuration Guide].
|
||||
For more information on how to set up and configure a Docker registry, see the link:https://docs.docker.com/registry/configuration/[Docker Registry Configuration Guide].
|
||||
|
||||
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ WARNING: Don't forget to configure the `rootcertbundle` field with the location
|
|||
|
||||
=== Docker Registry Environment Variable Override Installation
|
||||
|
||||
Often times it is appropriate to use a simple environment variable override for develop or POC Docker registries. While this apporach is usually not recommended for production use, it can be helpful when one requires quick-and-dirty way to stand up a registry. Simply use the _Variable Override_ Format Option from the client installation tab, and an output should appear like the one below:
|
||||
Often times it is appropriate to use a simple environment variable override for develop or POC Docker registries. While this approach is usually not recommended for production use, it can be helpful when one requires quick-and-dirty way to stand up a registry. Simply use the _Variable Override_ Format Option from the client installation tab, and an output should appear like the one below:
|
||||
|
||||
REGISTRY_AUTH_TOKEN_REALM: http://localhost:8080/auth/auth/realms/master/protocol/docker-v2/auth
|
||||
REGISTRY_AUTH_TOKEN_SERVICE: docker-test
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ propagated by {project_name} to applications using cookie store. Hence it's reco
|
|||
In deployment scenarios where {project_name} and the application is hosted on the same domain (through a reverse proxy or load balancer) it can be
|
||||
convenient to use relative URI options in your client configuration.
|
||||
|
||||
With relative URIs the URI is resolved as relative to the URL of the URL used to access {project_name}.
|
||||
With relative URIs the URI is resolved as relative to the URL used to access {project_name}.
|
||||
|
||||
For example if the URL to your application is `$$https://acme.org/myapp$$` and the URL to {project_name} is `$$https://acme.org/auth$$`, then you can use
|
||||
the redirect-uri `/myapp` instead of `$$https://acme.org/myapp$$`.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
===== Securing an Apache Camel Application
|
||||
|
||||
You can secure Apache camel endpoints implemented with the http://camel.apache.org/jetty.html[camel-jetty] component by adding securityHandler with `KeycloakJettyAuthenticator` and the proper security constraints injected. You can add the `OSGI-INF/blueprint/blueprint.xml` file to your camel application with a similar configuration as below. The roles, security constraint mappings, and {project_name} adapter configuration might differ slightly depending on your environment and needs.
|
||||
You can secure Apache Camel endpoints implemented with the http://camel.apache.org/jetty.html[camel-jetty] component by adding securityHandler with `KeycloakJettyAuthenticator` and the proper security constraints injected. You can add the `OSGI-INF/blueprint/blueprint.xml` file to your Camel application with a similar configuration as below. The roles, security constraint mappings, and {project_name} adapter configuration might differ slightly depending on your environment and needs.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Camel RestDSL is a Camel feature used to define your REST endpoints in a fluent
|
|||
|
||||
The way to configure the integration mechanism depends on the Camel component for which you configure your RestDSL-defined routes.
|
||||
|
||||
The following example shows how to configure integration using the jetty component, with references to some of the beans defined in previous Blueprint example.
|
||||
The following example shows how to configure integration using the Jetty component, with references to some of the beans defined in previous Blueprint example.
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
To run your CXF endpoints secured by {project_name} on separate Jetty engines, complete the following steps:
|
||||
|
||||
. Add `META-INF/spring/beans.xml` to your application, and in it, declare `httpj:engine-factory` with Jetty SecurityHandler with injected `KeycloakJettyAuthenticator`. The configuration for a CFX JAX-wS application might resemble this one:
|
||||
. Add `META-INF/spring/beans.xml` to your application, and in it, declare `httpj:engine-factory` with Jetty SecurityHandler with injected `KeycloakJettyAuthenticator`. The configuration for a CFX JAX-WS application might resemble this one:
|
||||
+
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ You must first install the `keycloak` feature in the JBoss Fuse environment. The
|
|||
|
||||
====== Installing from the Maven Repository
|
||||
|
||||
As a prequisite, you must be online and have access to the Maven repository.
|
||||
As a prerequisite, you must be online and have access to the Maven repository.
|
||||
|
||||
ifeval::[{project_community}==true]
|
||||
For community it's sufficient to be online as all the artifacts and 3rd party dependencies should be available in the maven central repository.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ which enables a smooth Web based SSO experience.
|
|||
The client eventually receives the tokens (access_token, refresh_token,
|
||||
id_token) which can then be used to call backend services.
|
||||
|
||||
The `KeycloakInstalled` adapter provides support for reneval of stale tokens.
|
||||
The `KeycloakInstalled` adapter provides support for renewal of stale tokens.
|
||||
|
||||
[[_installed_adapter_installation]]
|
||||
===== Adapter Installation
|
||||
|
|
@ -54,7 +54,7 @@ The `KeycloakInstalled` adapter provides support for reneval of stale tokens.
|
|||
|
||||
===== Client Configuration
|
||||
|
||||
The application needs to be configured as a `public` openid connect client with
|
||||
The application needs to be configured as a `public` OpenID Connect client with
|
||||
`Standard Flow Enabled` and pass:[http://localhost:*] as an allowed `Valid Redirect URI`.
|
||||
|
||||
===== Usage
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Let's go over these steps.
|
|||
Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on the Keycloak download site.
|
||||
They are also available as a maven artifact.
|
||||
|
||||
You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/current/startup-base-and-home.html[base directory.]
|
||||
You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/current/startup-base-and-home.html[base directory].
|
||||
Including adapter's jars within your WEB-INF/lib directory will not work!
|
||||
In the example below, the Jetty base is named `your-base`:
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ 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 <<_java_adapter_config,Java adapter configuration>> section.
|
||||
The format of this config file is described in the <<_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.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ To add it manually and if you are using Maven, add the following to your depende
|
|||
|
||||
----
|
||||
|
||||
Make also sure to add the Adapter BOM dependency :
|
||||
Make also sure to add the Adapter POM dependency :
|
||||
|
||||
[source,xml,subs="attributes+"]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -75,9 +75,9 @@ Spring Security's `SessionFixationProtectionStrategy` is currently not supported
|
|||
If the session identifier changes, universal log out will not work because Keycloak is unaware of the new session identifier.
|
||||
|
||||
TIP: The `@KeycloakConfiguration` annotation is a metadata annotion that defines all annotations that are needed to integrate
|
||||
KeyCloak in Spring security. If you have a complexe Spring security setup you can simply have a look ath the annotations of
|
||||
{project_name} in Spring Security. If you have a complexe Spring Security setup you can simply have a look ath the annotations of
|
||||
the `@KeycloakConfiguration` annotation and create your own custom meta annotation or just use specific Spring annotations
|
||||
for the KeyCloak adapter.
|
||||
for the {project_name} adapter.
|
||||
|
||||
====== XML Configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ 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 <<_java_adapter_config,Java adapter configuration>>
|
||||
The format of this config file is described in the <<_java_adapter_config,Java adapter configuration>>
|
||||
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This is a Jetty specific config file and you must define a Keycloak specific aut
|
|||
----
|
||||
|
||||
Next you must create a `keycloak-saml.xml` adapter config file within the `WEB-INF` directory of your WAR.
|
||||
The format of this config file is describe in the <<_saml-general-config,General Adapter Config>> section.
|
||||
The format of this config file is described in the <<_saml-general-config,General Adapter Config>> 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:
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ This is a Tomcat specific config file and you must define a Keycloak specific Va
|
|||
----
|
||||
|
||||
Next you must create a `keycloak-saml.xml` adapter config file within the `WEB-INF` directory of your WAR.
|
||||
The format of this config file is describe in the <<_saml-general-config,General Adapter Config>> section.
|
||||
The format of this config file is described in the <<_saml-general-config,General Adapter Config>> 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:
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ To configure the IdP to supply the user's groups as as a SAML attribute, complet
|
|||
. From the Mapper Type drop-down list select *Group list*.
|
||||
. Set Name to "group list."
|
||||
. Set the SAML attribute name to "groups."
|
||||
. Click *Save.*
|
||||
. Click *Save*.
|
||||
|
||||
The remaining steps are performed on $sp_host.
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ an additional `account-link-url` claim if the user does not have a link to an id
|
|||
for a client initiated link request.
|
||||
|
||||
NOTE: Token exchange setup requires knowledge of fine grain admin permissions (See the link:{adminguide_link}[{adminguide_name}] for more information). You will need to grant clients
|
||||
permission to exchange. This is discusssed more later in this chapter.
|
||||
permission to exchange. This is discussed more later in this chapter.
|
||||
|
||||
The rest of this chapter discusses the setup requirements and provides examples for different exchange scenarios.
|
||||
For simplicity's sake, let's call a token minted by the current realm as an _internal_ token and a token minted by
|
||||
|
|
@ -212,7 +212,7 @@ image:{project_images}/exchange-idp-permission-unset.png[]
|
|||
|
||||
Toggle the `Permissions Enabled` switch to true.
|
||||
|
||||
.Identity Provier Permission
|
||||
.Identity Provider Permission
|
||||
image:{project_images}/exchange-idp-permission-set.png[]
|
||||
|
||||
You should see a `token-exchange` link on the page. Click that to start defining the permission. It will bring you
|
||||
|
|
@ -284,7 +284,7 @@ this JSON document:
|
|||
|
||||
The `error` claim will be either `token_expired` or `not_linked`. The `account-link-url` claim is provided
|
||||
so that the client can perform link:{developerguide_link}[Client Initiated Account Linking]. Most (all?)
|
||||
providers requiring linking through browser OAuth protocol. With the `account-link-url` just add a `redirect_uri`
|
||||
providers are requiring linking through browser OAuth protocol. With the `account-link-url` just add a `redirect_uri`
|
||||
query parameter to it and you can forward browsers to perform the link.
|
||||
|
||||
=== External Token to Internal Token Exchange
|
||||
|
|
@ -407,7 +407,7 @@ WARNING: It is very risky to enable direct naked impersonation for a client. If
|
|||
If the `audience` parameter is provided, then the calling client must have permission to exchange to the client. How
|
||||
to set this up is discussed earlier in this chapter.
|
||||
|
||||
Additionaly, the calling client must be granted permission to impersonate users. In the admin console, go to the
|
||||
Additionally, the calling client must be granted permission to impersonate users. In the admin console, go to the
|
||||
`Users` screen and click on the `Permissions` tab.
|
||||
|
||||
.Users Permission
|
||||
|
|
@ -415,7 +415,7 @@ image:{project_images}/exchange-users-permission-unset.png[]
|
|||
|
||||
Toggle the `Permissions Enabled` switch to true.
|
||||
|
||||
.Identity Provier Permission
|
||||
.Identity Provider Permission
|
||||
image:{project_images}/exchange-users-permission-set.png[]
|
||||
|
||||
You should see a `impersonation` link on the page. Click that to start defining the permission. It will bring you
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ domains or realms. An existing account can be linked with one or more identities
|
|||
based on the identity information obtained from them.
|
||||
|
||||
An identity provider is usually based on a specific protocol that is used to authenticate and communicate authentication and authorization information to their users.
|
||||
It can be a social provider such as Facebook, Google or Twitter. It can be a business partner whose users need to access your services. Or it an be a cloud-based identity
|
||||
It can be a social provider such as Facebook, Google or Twitter. It can be a business partner whose users need to access your services. Or it can be a cloud-based identity
|
||||
service that you want to integrate with.
|
||||
|
||||
Usually, identity providers are based on the following protocols:
|
||||
|
|
|
|||
Loading…
Reference in a new issue