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

Fix typos and improve readability (#381)

Browse source
This commit is contained in:
Kohei Tamura 2018-05-29 17:02:18 +09:00 committed by Stian Thorgersen
parent b44cfa64e8
commit 911336913b
34 changed files with 65 additions and 65 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
authorization_services/topics/auth-services-overview.adoc
View file

@ -13,7 +13,7 @@ mechanisms such as:
* **User-based access control (UBAC)**
* **Context-based access control (CBAC)**
* **Rule-based access control**
** Using Javascript
** Using JavaScript
** Using JBoss Drools
* **Time-based access control**
* **Support for custom access control mechanisms (ACMs) through a Policy Provider Service Provider Interface (SPI)**

2
authorization_services/topics/enforcer-claim-information-point.adoc
View file

@ -10,7 +10,7 @@ to the policy-enforcer in order to resolve claims from different sources, such a
* Static values defined in configuration
* Any other source by implementing the Claim Information Provider SPI
When pushing claims to the {project_name} server, policies can base decisions not only on who an user is but also by taking
When pushing claims to the {project_name} server, policies can base decisions not only on who a user is but also by taking
context and contents into account, based on who, what, why, when, where, and which for a given transaction. It is all about
Contextual-based Authorization and how to use runtime information in order to support fine-grained authorization decisions.

4
getting_started/topics/secure-jboss-app/install-client-adapter.adoc
View file

@ -31,14 +31,14 @@ $ ./jboss-cli.sh --file=adapter-install-offline.cli
----
ifeval::[{project_community}==true]
.Wildfly 11 and Linux/Unix
.WildFly 11 and Linux/Unix
[source]
----
$ cd bin
$ ./jboss-cli.sh --file=adapter-elytron-install-offline.cli
----
.Wildfly 11 and Windows
.WildFly 11 and Windows
[source]
----
> cd bin

2
internal_resources/styleguide.adoc
View file

@ -36,7 +36,7 @@ Writers will also refer to these:
* Do not use Latin abbreviations, such as e.g., etc., and i.e.
** Instead, use "and so on" when you list a clear sequence of elements, such as "1, 2, 3, and
so on". Otherwise, rewrite the sentence to replace etc. with something more descriptive,
such as "and other output."
such as "and other output".
** Instead of i.e. use "that is".
** Instead of e.g. use "for example" or "such as".
* Do not use "&" in place of "and".

2
internal_resources/testing.adoc
View file

@ -7,7 +7,7 @@ Currently we are testing the following:
* Variables - check if there are variables that are not resolved
* Includes - check if there are includes where the included file is not found
* Images - check if there are images included that are not missing
* Internal links - check that all internal links (HTML anchors) point to an valid id
* Internal links - check that all internal links (HTML anchors) point to a valid id
* External links - check that all external links work, including HTML anchors
More details about each test below and what to do if the tests are not working.

4
openshift/content/advanced_concepts/advanced_concepts.adoc
View file

@ -274,7 +274,7 @@ When deploying RH-SSO application template, *_SSO_ADMIN_USERNAME_* and *_SSO_ADM
[IMPORTANT]
====
The lifespan of the RH-SSO server's administrator account depends upon the the storage type used to store the RH-SSO server's database:
The lifespan of the RH-SSO server's administrator account depends upon the storage type used to store the RH-SSO server's database:
* For an in-memory database mode (*_sso72-https_* and *_sso72-x509-https_* templates) the account exists throughout the lifecycle of the particular RH-SSO pod (stored account data is lost upon pod destruction),
* For an ephemeral database mode (*_sso72-mysql_* and *_sso72-postgresql_* templates) the account exists throughout the lifecycle of the database pod (even if the RH-SSO pod is destructed, the stored account data is preserved under the assumption that the database pod is still running),
@ -351,7 +351,7 @@ sh-4.2$ ./jboss-cli.sh --connect ':reload'
====
When restarting the server it is important to restart just the JBoss EAP process within the running RH-SSO container, and not the whole container. This is because restarting the whole container will recreate it from scratch, without the RH-SSO server administration account for the `master` realm.
====
. Log in to the `master` realm's administration console of the RH-SSO server using the the credentials created in the steps above. In the browser, navigate to *\http://sso-<project-name>.<hostname>/auth/admin* for the RH-SSO web server, or to *\https://secure-sso-<project-name>.<hostname>/auth/admin* for the encrypted RH-SSO web server, and specify the user name and password used to create the administrator user.
. Log in to the `master` realm's administration console of the RH-SSO server using the credentials created in the steps above. In the browser, navigate to *\http://sso-<project-name>.<hostname>/auth/admin* for the RH-SSO web server, or to *\https://secure-sso-<project-name>.<hostname>/auth/admin* for the encrypted RH-SSO web server, and specify the user name and password used to create the administrator user.
=== Deployment Process

4
openshift/content/tutorials/tutorials.adoc
View file

@ -1510,7 +1510,7 @@ Export the SAML Keys:
Download the Client Adapter:
. Click *Installation*.
. Use the *Format Option* drop-down menu to select a format. This example uses *Keycloak SAML Wildfly/JBoss Subsystem*.
. Use the *Format Option* drop-down menu to select a format. This example uses *Keycloak SAML WildFly/JBoss Subsystem*.
. Click *Download* and save the file *keycloak-saml-subsystem.xml*.
The *keystore-saml.jks* will be used with the other EAP keystores in the next section to create an OpenShift secret for the EAP application project. Copy the *keystore-saml.jks* file to an OpenShift node. +
@ -1583,7 +1583,7 @@ The *keycloak-saml-subsystem.xml*, exported from the RH-SSO client in a previous
+
The mount path of the *keystore-saml.jks* (in this example *_/etc/eap-secret-volume/keystore-saml.jks_*) can be specified in the application template with the parameter *EAP_HTTPS_KEYSTORE_DIR*. +
The aliases and passwords for the *PrivateKey* and the *Certificate* were configured when the SAML Keys were exported from the RH-SSO client.
. Delete the second *<CertificatePem>* tag and key and replace it with the the realm certificate information:
. Delete the second *<CertificatePem>* tag and key and replace it with the realm certificate information:
+
----
...

4
securing_apps/topics/client-registration.adoc
View file

@ -101,7 +101,7 @@ To do this include the following header in the request:
Authorization: basic BASE64(client-id + ':' + client-secret)
----
To retrieve the Adapter Configuration then perfrom an HTTP GET request to `/realms/<realm>/clients-registrations/install/<client id>`.
To retrieve the Adapter Configuration then perform an HTTP GET request to `/realms/<realm>/clients-registrations/install/<client id>`.
No authentication is required for public clients.
This means that for the JavaScript adapter you can load the client configuration directly from {project_name} using the above URL.
@ -187,7 +187,7 @@ Currently we have these policy implementations:
* Trusted Hosts Policy - You can configure list of trusted hosts and trusted domains. Request to Client Registration Service can be sent just from those hosts or domains.
Request sent from some untrusted IP will be rejected. URLs of newly registered client must also use just those trusted hosts or domains. For example it won't be allowed
to set `Redirect URI` of client pointing to some untrusted host. By default, there is not any whitelisted host, so anonymous client registration is de-facto disabled by default.
to set `Redirect URI` of client pointing to some untrusted host. By default, there is not any whitelisted host, so anonymous client registration is de-facto disabled.
* Consent Required Policy - Newly registered clients will have `Consent Allowed` switch enabled. So after successful authentication, user will always
see consent screen when he needs to approve personal info and permissions (protocol mappers and roles). It means that client won't have access to any personal

2
securing_apps/topics/oidc/java/adapter-context.adoc
View file

@ -10,7 +10,7 @@ httpServletRequest
.getAttribute(KeycloakSecurityContext.class.getName());
----
Or, it is available in secure and insecure requests in the HttpSession:
Or, it is available in insecured requests in the HttpSession:
[source,java]
----

2
securing_apps/topics/oidc/java/fuse/hawtio.adoc
View file

@ -16,7 +16,7 @@ hawtio.rolePrincipalClasses=org.keycloak.adapters.jaas.RolePrincipal,org.apache.
. Create a client in the {project_name} administration console in your realm. For example, in the {project_name} `demo` realm, create a client `hawtio-client`, specify `public` as the Access Type, and specify a redirect URI pointing to Hawtio: \http://localhost:8181/hawtio/*. You must also have a corresponding Web Origin configured (in this case, \http://localhost:8181).
. Create the `keycloak-hawtio-client.json` file in the `$FUSE_HOME/etc` directory using content similar to that shown in the example below. Change the `realm`, `resource`, and `auth-server-url` properties according to your {project_name} environment. The `resource` property must point to the client created in the previous step. This file is used by the client (Hawtio Javascript application) side.
. Create the `keycloak-hawtio-client.json` file in the `$FUSE_HOME/etc` directory using content similar to that shown in the example below. Change the `realm`, `resource`, and `auth-server-url` properties according to your {project_name} environment. The `resource` property must point to the client created in the previous step. This file is used by the client (Hawtio JavaScript application) side.
+
[source,json]
----

4
securing_apps/topics/oidc/java/java-adapter-config.adoc
View file

@ -45,7 +45,7 @@ This is what one might look like:
You can use `${...}` enclosure for system property replacement. For example `${jboss.server.config.dir}` would be replaced by `/path/to/{project_name}`.
Replacement of environment variables is also supported via the `env` prefix, e.g. `${env.MY_ENVIRONMENT_VARIABLE}`.
The initial config file can be obtained from the the admin console. This can be done by opening the admin console, select `Clients` from the menu and clicking
The initial config file can be obtained from the admin console. This can be done by opening the admin console, select `Clients` from the menu and clicking
on the corresponding client. Once the page for the client is opened click on the `Installation` tab and select `Keycloak OIDC JSON`.
Here is a description of each configuration option:
@ -136,7 +136,7 @@ enable-basic-auth::
The default value is _false_.
expose-token::
If `true`, an authenticated browser client (via a Javascript HTTP invocation) can obtain the signed access token via the URL `root/k_query_bearer_token`.
If `true`, an authenticated browser client (via a JavaScript HTTP invocation) can obtain the signed access token via the URL `root/k_query_bearer_token`.
This is _OPTIONAL_.
The default value is _false_.

8
securing_apps/topics/oidc/java/jboss-adapter.adoc
View file

@ -1,7 +1,7 @@
[[_jboss_adapter]]
ifeval::[{project_community}==true]
==== JBoss EAP/Wildfly Adapter
==== JBoss EAP/WildFly Adapter
endif::[]
ifeval::[{project_product}==true]
==== JBoss EAP Adapter
@ -29,7 +29,7 @@ Adapters are available as a separate archive depending on what server version yo
NOTE: {appserver_name} should be running when you install the adapter. If you have either one running, you must stop it before installing and then restart it after installation is complete.
ifeval::[{project_community}==true]
Install on Wildfly 9, 10 or 11:
Install on WildFly 9, 10 or 11:
[source, subs="attributes"]
----
@ -37,7 +37,7 @@ $ cd $WILDFLY_HOME
$ unzip keycloak-wildfly-adapter-dist-{project_version}.zip
----
Install on Wildfly 8:
Install on WildFly 8:
[source, subs="attributes"]
----
@ -138,7 +138,7 @@ NOTE: The offline script is not available for JBoss EAP 6.4
Alternatively, if the server is running execute:
ifeval::[{project_community}==true]
.Wildfly 11
.WildFly 11
[source]
----
$ ./bin/jboss-cli.sh --file=adapter-elytron-install.cli

2
securing_apps/topics/oidc/javascript-adapter.adoc
View file

@ -1,5 +1,5 @@
[[_javascript_adapter]]
=== Javascript Adapter
=== JavaScript Adapter
{project_name} comes with a client-side JavaScript library that can be used to secure HTML5/JavaScript applications. The JavaScript adapter has built-in support for Cordova applications.

2
securing_apps/topics/oidc/nodejs-adapter.adoc
View file

@ -115,7 +115,7 @@ Once instantiated, install the middleware into your connect-capable app:
Simple authentication::
To enforce that an user must be authenticated before accessing a resource,
To enforce that a user must be authenticated before accessing a resource,
simply use a no-argument version of `keycloak.protect()`:
[source,javascript]

2
securing_apps/topics/oidc/oidc-generic.adoc
View file

@ -109,7 +109,7 @@ For more details refer to the http://openid.net/specs/openid-connect-core-1_0.ht
===== Implicit
The Implicit flow redirects works similarly to the Authorization Code flow, but instead of returning a Authorization Code the Access Token and ID Token is
The Implicit flow redirects works similarly to the Authorization Code flow, but instead of returning an Authorization Code the Access Token and ID Token is
returned. This reduces the need for the extra invocation to exchange the Authorization Code for an Access Token. However, it does not include a Refresh
Token. This results in the need to either permit Access Tokens with a long expiration, which is problematic as it's very hard to invalidate these. Or
requires a new redirect to obtain new Access Token once the initial Access Token has expired. The Implicit flow is useful if the application only wants to

6
securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc
View file

@ -5,7 +5,7 @@
Each adapter is a separate download on the {project_name} download site.
ifeval::[{project_community}==true]
Install on Wildfly 9 or 10, 11 or JBoss EAP 7:
Install on WildFly 9 or 10, 11 or JBoss EAP 7:
[source]
----
@ -42,7 +42,7 @@ $ unzip rh-sso-saml-eap6-adapter.zip
endif::[]
These zip files create new JBoss Modules specific to the Wildfly/JBoss EAP SAML Adapter within your Wildfly or JBoss EAP distro.
These zip files create new JBoss Modules specific to the WildFly/JBoss EAP SAML Adapter within your WildFly or JBoss EAP distro.
After adding the modules, you must then enable the {project_name} SAML Subsystem within your app server's server configuration: `domain.xml` or `standalone.xml`.
@ -50,7 +50,7 @@ There is a CLI script that will help you modify your server configuration.
Start the server and run the script from the server's bin directory:
ifeval::[{project_community}==true]
.Wildfly 11
.WildFly 11
[source]
----
$ ./bin/jboss-cli.sh --file=adapter-elytron-install-saml.cli

6
securing_apps/topics/saml/java/logout.adoc
View file

@ -9,13 +9,13 @@ This will log you out if you have an SSO session with your browser.
===== Logout in Clustered Environment
Internally, the SAML adapter stores a mapping between the SAML session index, principal name (when known), and HTTP session ID.
This mapping can be maintained in JBoss application server family (Wildfly 10/11, EAP 6/7) across cluster for distributable
This mapping can be maintained in JBoss application server family (WildFly 10/11, EAP 6/7) across cluster for distributable
applications. As a precondition, the HTTP sessions need to be distributed across cluster (i.e. application is marked with
`<distributable/>` tag in application's `web.xml`).
To enable the functionality, add the following section to your `/WEB_INF/web.xml` file:
For EAP 7, Wildfly 10/11:
For EAP 7, WildFly 10/11:
[source,xml]
----
@ -51,7 +51,7 @@ to SAML session index to HTTP session mapping which would lead to unsuccessful l
[[_saml_logout_in_cross_dc]]
===== Logout in Cross DC Scenario
The cross DC scenario only applies to Wildfly 10 and higher, and EAP 7 and higher.
The cross DC scenario only applies to WildFly 10 and higher, and EAP 7 and higher.
Special handling is needed for handling sessions that span multiple data centers. Imagine the following scenario:

4
securing_apps/topics/saml/java/saml-jboss-adapter.adoc
View file

@ -1,14 +1,14 @@
[[_saml_jboss_adapter]]
ifeval::[{project_community}==true]
==== JBoss EAP/Wildfly Adapter
==== JBoss EAP/WildFly Adapter
endif::[]
ifeval::[{project_product}==true]
==== JBoss EAP Adapter
endif::[]
ifeval::[{project_community}==true]
To be able to secure WAR apps deployed on JBoss EAP or Wildfly, you must install and configure the {project_name} SAML Adapter Subsystem.
To be able to secure WAR apps deployed on JBoss EAP or WildFly, you must install and configure the {project_name} SAML Adapter Subsystem.
endif::[]
ifeval::[{project_product}==true]
To be able to secure WAR apps deployed on JBoss EAP, you must install and configure the {project_name} SAML Adapter Subsystem.

4
securing_apps/topics/saml/mod-auth-mellon.adoc
View file

@ -189,8 +189,8 @@ To configure the IdP to supply the user's groups as as a SAML attribute, complet
. Click the Mappers tab of the client.
. In the upper right corner of the Mappers page, click *Create*.
. From the Mapper Type drop-down list select *Group list*.
. Set Name to "group list."
. Set the SAML attribute name to "groups."
. Set Name to "group list".
. Set the SAML attribute name to "groups".
. Click *Save*.
The remaining steps are performed on $sp_host.

4
securing_apps/topics/token-exchange/token-exchange.adoc
View file

@ -8,7 +8,7 @@ include::../templates/techpreview.adoc[]
In {project_name}, token exchange is the process of using a set of credentials or token to obtain an entirely different token.
A client may want to invoke on a less trusted application so it may want to downgrade the current token it has.
A client may want to exchange a {project_token} for a token stored for a linked social provider account.
A client may want to exchange a {project_name} token for a token stored for a linked social provider account.
You may want to trust external tokens minted by other {project_name} realms or foreign IDPs. A client may have a need
to impersonate a user. Here's a short summary of the current capabilities of {project_name} around token exchange.
@ -85,7 +85,7 @@ a JSON document as described in the link:https://www.ietf.org/id/draft-ietf-oaut
Clients requesting a refresh token will get back both an access and refresh token in the response. Clients requesting only
access token type will only get an access token in the response. Expiration information may or may not be included for
clients requesting a an external issuer through the `requested_issuer` paramater.
clients requesting an external issuer through the `requested_issuer` paramater.
Error responses generally fall under the 400 HTTP response code category, but other error status codes may be returned
depending on the severity of the error. Error responses may include content depending on the `requested_issuer`.

8
server_admin/topics/admin-cli.adoc
View file

@ -91,7 +91,7 @@ c:\> kcadm config truststore --trustpass %PASSWORD% %HOMEPATH%\.keycloak\trustst
=== Authenticating
When you log in with the Admin CLI, you specify a server endpoint URL and a realm, and then you specify a user name. Another option is to specify only a clientId, which results in using a special "service account." When you log in using a user name, you must use a password for the specified user. When you log in using a clientId, you only need the client secret, not the user password. You could also use [command]`Signed JWT` instead of the client secret.
When you log in with the Admin CLI, you specify a server endpoint URL and a realm, and then you specify a user name. Another option is to specify only a clientId, which results in using a special "service account". When you log in using a user name, you must use a password for the specified user. When you log in using a clientId, you only need the client secret, not the user password. You could also use [command]`Signed JWT` instead of the client secret.
Make sure the account used for the session has the proper permissions to invoke Admin REST API operations. For example, the `realm-admin` role of the `realm-management` client allows the user to administer the realm within which the user is defined.
@ -119,7 +119,7 @@ Run the [command]`kcadm.sh config credentials --help` command for more informati
[[_working_with_alternative_configurations]]
=== Working with alternative configurations
By default, the Admin CLI automatically maintains a configuration file called [filename]kcadm.config located under the user's home directory. In Linux-based systems, the full path name is [filename]$HOME/.keycloak/kcadm.config. On Windows, the full path name is [filename]%HOMEPATH%\.keycloak\kcadm.config. You can use the [command]`--config` option to point to a different file or location so you can maintain multiple authenticated sessions in parallel.
By default, the Admin CLI automatically maintains a configuration file called [filename]`kcadm.config` located under the user's home directory. In Linux-based systems, the full path name is [filename]`$HOME/.keycloak/kcadm.config`. On Windows, the full path name is [filename]`%HOMEPATH%\.keycloak\kcadm.config`. You can use the [command]`--config` option to point to a different file or location so you can maintain multiple authenticated sessions in parallel.
[NOTE]
====
@ -858,7 +858,7 @@ $ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/provide
----
[discrete]
==== Getting a Wildfly subsystem adapter configuration for a specific client
==== Getting a WildFly subsystem adapter configuration for a specific client
Use a client's ID to construct an endpoint URI that targets a specific client, such as [filename]`clients/ID/installation/providers/keycloak-oidc-jboss-subsystem`.
@ -1635,7 +1635,7 @@ $ kcadm.sh create components -r demorealm -s name=msad-user-account-control-mapp
----
[discrete]
==== Adding an user attribute LDAP mapper
==== Adding a user attribute LDAP mapper
. Run the [command]`create` command on the [filename]`components` endpoint.
. Set the [command]`providerType` attribute to [filename]`org.keycloak.storage.ldap.mappers.LDAPStorageMapper`.

2
server_admin/topics/admin-console-permissions/fine-grain.adoc
View file

@ -71,7 +71,7 @@ the `Authorization` link shown in the above image. Then click on the policies ta
There's a pull down menu on this page called `Create policy`. There's a multitude of policies
you can define. You can define a policy that is associated with a role or a group or even define
rules in Javascript. For this simple example, we're going to create a `User Policy`.
rules in JavaScript. For this simple example, we're going to create a `User Policy`.
.User Policy
image:{project_images}/fine-grain-client-user-policy.png[]

2
server_admin/topics/authentication/kerberos.adoc
View file

@ -65,7 +65,7 @@ The Keytab file `/tmp/http.keytab` will need to be accessible on the host where
You need to install a kerberos client on your machine. This is also platform dependent.
If you are on Fedora, Ubuntu or RHEL, you can install the package `freeipa-client`, which contains a Kerberos client and several other utilities.
Configure the kerberos client (on linux it's in file `/etc/krb5.conf` ). You need to put your Kerberos realm and at least configure the HTTP domains your server will be running on.
Configure the kerberos client (on Linux it's in file `/etc/krb5.conf` ). You need to put your Kerberos realm and at least configure the HTTP domains your server will be running on.
For the example realm MYDOMAIN.ORG you may configure the `domain_realm` section like this:
[source]

12
server_admin/topics/authentication/x509.adoc
View file

@ -54,10 +54,10 @@ Other Features: Extended Certificate Validation::
==== Enable X.509 Client Certificate User Authentication
The following sections describe how to configure Wildfly/Undertow and the {project_name} Server to enable X.509 client certificate authentication.
The following sections describe how to configure WildFly/Undertow and the {project_name} Server to enable X.509 client certificate authentication.
Enable mutual SSL in WildFly::
See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in Wildfly.
See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in WildFly.
* Open {project_dirref}/standalone/configuration/standalone.xml and add a new realm:
```xml
@ -112,7 +112,7 @@ The password to open the truststore
Enable https listener::
See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in Wildfly.
See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in WildFly.
* Add the <https-listener> element as shown below:
@ -139,7 +139,7 @@ If set to `REQUESTED`, the server will optionally ask for a client certificate.
* Select a realm, click on Authentication link, select the "Browser" flow
* Make a copy of the built-in "Browser" flow. You may want to give the new flow a distinctive name, i.e. "X.509 Browser"
* Using the drop down, select the copied flow, and click on "Add Execution"
* Using the drop down, select the copied flow, and click on "Add execution"
* Select "X509/Validate User Form" using the drop down and click on "Save"
image:images/x509-execution.png[]
@ -196,8 +196,8 @@ If set, X.509 client certificate authentication will not prompt the user to conf
* Using {project_name} admin console, click on "Authentication" and select the "Direct Grant" flow,
* Make a copy of the build-in "Direct Grant" flow. You may want to give the new flow a distinctive name, i.e. "X509 Direct Grant",
* Delete "Validate Username" and "Password" authenticators,
* Click on "Execution" and add "X509/Validate Username" and click on "Save" to add the execution step to the parent flow.
* Delete "Username Validation" and "Password" authenticators,
* Click on "Add execution" and add "X509/Validate Username" and click on "Save" to add the execution step to the parent flow.
image:images/x509-directgrant-execution.png[]

2
server_admin/topics/clients/protocol-mappers.adoc
View file

@ -32,7 +32,7 @@ are common to all mappers:
Consent Required::
If your client requires consent, this mapper will be displayed on the consent screen shown to the user.
Consent Text::
If your client requires consent and the `Consent` switch is on, this is the text that will be displayed by the user.
If your client requires consent and the `Consent Required` switch is on, this is the text that will be displayed by the user.
The value for this text is localizable by specifying a substitution variable with `$\{var-name}` strings. The
localized value is then configured within property files in your theme. See the link:{developerguide_link}[{developerguide_name}]
for more information on localization.

8
server_admin/topics/identity-broker/social/openshift.adoc
View file

@ -1,10 +1,10 @@
==== Openshift
==== OpenShift
NOTE: Openshift Online is currently in the developer preview mode. This documentation has been based on on-premise installations and local `minishift` development environment.
NOTE: OpenShift Online is currently in the developer preview mode. This documentation has been based on on-premise installations and local `minishift` development environment.
There are a just a few steps you have to complete to be able to login to OpenShift. First, go to the `Identity Providers` left menu item
and select `Openshift` from the `Add provider` drop down list. This will bring you to the `Add identity provider` page.
and select `OpenShift` from the `Add provider` drop down list. This will bring you to the `Add identity provider` page.
.Add Identity Provider
image:images/openshift-add-identity-provider.png[]
@ -36,4 +36,4 @@ grantMethod: prompt <4>
Use client ID and secret defined by `oc create` command to enter them back on the {project_name} `Add identity provider` page.
Go back to {project_name} and specify those items.
Please refer to https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth[official Openshift documentation] for more detailed guides.
Please refer to https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth[official OpenShift documentation] for more detailed guides.

4
server_admin/topics/realms/email.adoc
View file

@ -21,13 +21,13 @@ From::
`From` denotes the address used for the `From` SMTP-Header for the emails sent.
From Display Name::
`From Display Name` allows to configure an user friendly email address aliases (optional). If not set the plain `From` email address will be displayed in email clients.
`From Display Name` allows to configure a user friendly email address aliases (optional). If not set the plain `From` email address will be displayed in email clients.
Reply To::
`Reply To` denotes the address used for the `Reply-To` SMTP-Header for the mails sent (optional). If not set the plain `From` email address will be used.
Reply To Display Name::
`Reply To Display Name` allows to configure an user friendly email address aliases (optional). If not set the plain `Reply To` email address will be displayed.
`Reply To Display Name` allows to configure a user friendly email address aliases (optional). If not set the plain `Reply To` email address will be displayed.
Envelope From::
`Envelope From` denotes the https://en.wikipedia.org/wiki/Bounce_address[Bounce Address] used for the `Return-Path` SMTP-Header for the mails sent (optional).

2
server_admin/topics/sso-protocols/saml.adoc
View file

@ -7,7 +7,7 @@ of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0
that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption
is used to verify requests and responses.
There is really two types of use cases when using SAML. The first is an application that asks the {project_name} server to authenticate
There are really two types of use cases when using SAML. The first is an application that asks the {project_name} server to authenticate
a user for them. After a successful login, the application will receive an XML document that contains
something called a SAML assertion that specify various attributes about the user. This XML document is digitally signed by
the realm and contains access information (like user role mappings) that the application can use to determine what resources the user

4
server_admin/topics/user-federation.adoc
View file

@ -16,7 +16,7 @@ runtime. This common user model can then be mapped to OIDC token claims and SAM
External user databases rarely have every piece of data need to support all the features that {project_name} has.
In this case, the User Storage Provider can opt to store some things locally in the {project_name} user store.
Some providers even import the user locally and sync periodically with the external store. All this depends on the capabilities of the provider and how its configured. For example, your
external user store may not support OTP. Depending on the provider, this OTP support can be handled and stored by {project_name}
external user store may not support OTP. Depending on the provider, this OTP can be handled and stored by {project_name}.
=== Adding a Provider
@ -25,7 +25,7 @@ To add a storage provider go to the `User Federation` left menu item in the Admi
.User Federation
image:{project_images}/user-federation.png[]
On the right side, there is an `Add Provider` list box. Choose the provider type you want to add and you will be brought to the configuration page of that provider.
On the center, there is an `Add Provider` list box. Choose the provider type you want to add and you will be brought to the configuration page of that provider.
=== Dealing with Provider Failures

4
server_admin/topics/user-federation/ldap.adoc
View file

@ -30,7 +30,7 @@ a piece of data that a {project_name} feature needs that feature will not work.
The benefit to this approach is that you do not have the overhead of importing and synchronizing a copy of the LDAP user into the
{project_name} user database.
This storage mode is controled by the `Import Enabled` switch. Set to `On` to import users.
This storage mode is controled by the `Import Users` switch. Set to `On` to import users.
==== Edit Mode
@ -57,7 +57,7 @@ Console Display Name::
Name used when this provider is referenced in the admin console
Priority::
The priority of this provider when looking up users or for adding registrations.
The priority of this provider when looking up users or adding a user.
Sync Registrations::
Does your LDAP support adding new users? Click this switch if you want new users created by {project_name} in the admin console or the registration page

2
server_development/topics/auth-spi.adoc
View file

@ -723,7 +723,7 @@ You cannot modify built in flows, so, to add the Authenticator we've created you
I'm hoping the UI is intuitive enough so that you can figure out for yourself how to create a flow and add the FormAction.
Basically you'll have to copy the registration flow.
Then click Actions menu to the right of the Registration Form, and pick "Add Execution" to add a new execution.
Then click Actions menu to the right of the Registration Form, and pick "Add execution" to add a new execution.
You'll pick the FormAction from the selection list.
Make sure your FormAction comes after "Registration User Creation" by using the down errors to move it if your FormAction isn't already listed after "Registration User Creation". You want your FormAction to come after user creation because the success() method of Regsitration User Creation is responsible for creating the new UserModel.

2
server_development/topics/user-storage/simple-example.adoc
View file

@ -128,7 +128,7 @@ The `isValid()` method is responsible for validating passwords. The `CredentialI
===== CredentialInputUpdater Implementation
As noted before, the only reason we implement the `CredentialInputUpdater` interface in this example is to forbid modifications of user passwords. The reason we have to do this is because otherwise the runtime would allow the password to be overriden in {project_name} local storage. We'll talk more about this later in this chapter.
As noted before, the only reason we implement the `CredentialInputUpdater` interface in this example is to forbid modifications of user passwords. The reason we have to do this is because otherwise the runtime would allow the password to be overridden in {project_name} local storage. We'll talk more about this later in this chapter.
[source,java]
----

2
server_installation/topics/manage.adoc
View file

@ -46,4 +46,4 @@ connect
You may be thinking to yourself, "I didn't enter in any username or password!". If you run `jboss-cli` on the same machine
as your running standalone server or domain controller and your account has appropriate file permissions, you do not have
to setup or enter in a admin username and password. See the link:{appserver_admindoc_link}[_{appserver_admindoc_name}_] for more details on how to make things more secure if you are uncomfortable with that setup.
to setup or enter in an admin username and password. See the link:{appserver_admindoc_link}[_{appserver_admindoc_name}_] for more details on how to make things more secure if you are uncomfortable with that setup.

6
upgrading/topics/keycloak/changes.adoc
View file

@ -200,7 +200,7 @@ You also need to update `keycloak-server.json` as it's changed due to this.
==== Adapter Subsystems only bring in dependencies if Keycloak is on
Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into Wildfly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not.
Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into WildFly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not.
These libraries are now only added to your deployment if you have Keycloak authentication turned on for that adapter (via the subsystem, or auth-method in web.xml)
==== Client Registration service endpoints moved
@ -229,7 +229,7 @@ Same goes with mongo and Infinispan under modules keycloak-model-mongo and keycl
==== For adapters, session id changed after login
To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/Wildfly, Jetty 9), the Keycloak OIDC and SAML adapters will change the session id after login.
To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/WildFly, Jetty 9), the Keycloak OIDC and SAML adapters will change the session id after login.
You can turn off this behavior check adapter config switches.
==== SAML SP Client Adapter Changes
@ -540,7 +540,7 @@ Facebook admin console).
=== Migrating from 1.0 Alpha 1 to Alpha 2
* DB Schema has changed. We don't have any data migration utilities yet as of Alpha 2.
* JBoss and Wildfly adapters are now installed via a {appserver_name} subsystem. Please review the adapter
* JBoss and WildFly adapters are now installed via a {appserver_name} subsystem. Please review the adapter
installation documentation. Edits to standalone.xml are now required.
* There is a new credential type "secret". Unlike other credential types, it is stored in plain text in
the database and can be viewed in the admin console.