libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

QE feedback comments incorporated in upstream

Browse source
This commit is contained in:
--add 2016-06-01 15:22:02 +05:30
parent 0a1ca59906
commit 0cd2720b95
5 changed files with 11 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
topics/cache/disable.adoc vendored
View file

@ -10,13 +10,13 @@ Here's what the config looks like initially.
----
"userCache": {
"infinispan" : {
"default" : {
"enabled": true
}
},
"realmCache": {
"infinispan" : {
"default" : {
"enabled": true
}
},

5
topics/network/https.adoc
View file

@ -4,15 +4,12 @@
WARNING: {{book.project.name}} is not set up by default to handle SSL/HTTPS.
It is highly recommended that you either enable SSL on the {{book.project.name}} server itself or on a reverse proxy in front of the {{book.project.name}} server.
{{book.project.name}} can run out of the box without SSL/HTTPS so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172..16.x.x.
If you try to access {{book.project.name}} out of the box via a non-private IP address you will get an error.
This default behavior is defined by the SSL/HTTPS mode of each {{book.project.name}} realm. This is discussed in more detail in the
link:{{book.adminguide.link}}[{{book.adminguide.name}}], but let's give some context and a brief overview of these modes.
external::
{{book.project.name}} can run out of the box without SSL so long as you stick to private IP addresses like `localhost`, `127.0.0.1`, `10.0.x.x`, `192.168.x.x`, and `172..16.x.x`.
If you try to access {{book.project.name}} from a non-private IP adress you will get an error.
In case you don’t have HTTPS/SSL properly configured on the server and you try to access {{book.project.name}} from a non-private IP adress you will get an error.
none::
{{book.project.name}} does not require SSL. This should really only be used in development when you are playing around with things.

2
topics/network/outgoing.adoc
View file

@ -72,7 +72,7 @@ You can use _keytool_ to create a new truststore file or add trusted host certif
$ keytool -import -alias HOSTDOMAIN -keystore truststore.jks -file host-certificate.cer
----
The truststore is configured within the_keycloak-server.json_ file. The location of this file depends on your <<fake/../../operating-mode.adoc#_operating-mode, operating mode>>.
The truststore is configured within the _keycloak-server.json_ file. The location of this file depends on your <<fake/../../operating-mode.adoc#_operating-mode, operating mode>>.
You can add your truststore configuration by using the following template:
[source]

10
topics/operating-mode/domain.adoc
View file

@ -42,7 +42,7 @@ from the domain controller.
Various other chapters in this guide walk you through configuring various aspects like databases,
HTTP network connections, caches, and other infrastructure related things. While standalone mode uses the _standalone.xml_ file to configure these things,
domain mode uses the _.../domain/domain.xml_ configuration file. This is
domain mode uses the _.../domain/configuration/domain.xml_ configuration file. This is
where the domain profile and server group for the {{book.project.name}} server are defined.
@ -53,7 +53,7 @@ WARNING: Any changes you make to this file while the domain controller is runnin
by the server. Instead use the the command line scripting or the web console of {{book.appserver.name}}. See
the link:{{book.appserver.admindoc.link}}[{{book.appserver.admindoc.name}}] for more information.
Let's look at some aspects of this _domain.xml_ file. The `auth-serve-standalone` and `auth-server-clustered` `profile` XML block is where you are going to make the bulk of your configuration decisions.
Let's look at some aspects of this _domain.xml_ file. The `auth-server-standalone` and `auth-server-clustered` `profile` XML blocks are where you are going to make the bulk of your configuration decisions.
You'll be configuring things here like network connections, caches, and database connections.
@ -174,10 +174,10 @@ The structure of these per server directories ends up looking like any other {{b
.Working Directories
image:../../{{book.images}}/domain-server-dir.png[]
==== {{book.project.name}} JSon Configuration
==== {{book.project.name}} JSON Configuration
Unfortunately, there is no centralized way to manage the _keycloak.json_ file. You'll have to manage a copy of this file
in every server instance you deploy. This file must exist in the _.../domain/servers/{SERVER NAME}/configuration directory.
in every server instance you deploy. This file must exist in the _.../domain/servers/{SERVER NAME}/configuration directory._
.JSON Configuration
image:../../{{book.images}}/domain-json-config.png[]
@ -264,6 +264,8 @@ $ add-user.sh
To represent the user add the following to the server-identities definition <secret value="bWdtdDEyMyE=" />
----
NOTE: The add-user.sh does not add user to {{book.project.name}} Server but to Enterprise Application Platform. The credentials used and generated in the above script are only for example purpose. Please use the ones generated on your system.
Now cut and paste the secret value into the _.../domain/configuration/host-slave.xml_ file as follows:
[source,xml]

2
topics/operating-mode/standalone.adoc
View file

@ -46,7 +46,7 @@ WARNING: Any changes you make to this file while the server is running will not
==== Standalone {{book.project.name}} JSON Configuration
{{book.project.name}} has a json configuration file that is specific to {{book.project.name}} components. This configuration is located within
the file_.../standalone/configuration/keycloak.json_. This file is used to configure non-infrastructure level things that are
the file.../standalone/configuration/keycloak-server.json. This file is used to configure non-infrastructure level things that are
only applicable to {{book.project.name}}
.Standalone {{book.project.name}} Config File