RH602 and 642 updates
This commit is contained in:
Chuck Copello
parent
810e2d2137
commit
accf7795da
17 changed files with 65 additions and 78 deletions
|
|
@ -12,7 +12,7 @@
|
|||
"title": "Server Administration Guide",
|
||||
"project": {
|
||||
"name": "Red Hat Single Sign-On",
|
||||
"version": "7.0.0"
|
||||
"version": "7.1.0"
|
||||
},
|
||||
"community": false,
|
||||
"product": true,
|
||||
|
|
@ -20,16 +20,16 @@
|
|||
|
||||
"developerguide": {
|
||||
"name": "Server Developer Guide",
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-developer-guide/"
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.1-Beta/server-developer-guide/"
|
||||
|
||||
},
|
||||
"installguide": {
|
||||
"name": "Server Installation and Configuration Guide",
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-installation-and-configuration-guide/"
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.1-Beta/server-installation-and-configuration-guide/"
|
||||
},
|
||||
"adapterguide": {
|
||||
"name": "Securing Applications and Services Guide",
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/securing-applications-and-services-guide/"
|
||||
"link": "https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.1-Beta/securing-applications-and-services-guide/"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ The QR code you see in the screen shot can be scanned into the FreeOTP or Google
|
|||
.OTP Authenticator
|
||||
image:../{{book.images}}/account-service-authenticator.png[]
|
||||
|
||||
The `Federated Identity` menu item allows the user to link their account with an <<fake/../identity-broker.adoc#_identity_broker, identity broker>> (this is usually used to link social provier
|
||||
The `Federated Identity` menu item allows the user to link their account with an <<fake/../identity-broker.adoc#_identity_broker, identity broker>> (this is usually used to link social provider
|
||||
accounts together). This will show the list of external identity providers you have configured for your realm.
|
||||
|
||||
.Federated Identity
|
||||
|
|
@ -43,6 +43,3 @@ image:../{{book.images}}/account-service-apps.png[]
|
|||
|
||||
Like all UIs in {{book.project.name}}, the User Account Service is completely themeable and internationalizable.
|
||||
See the link:{{book.developerguide.link}}[{{book.developerguide.name}}] for more details.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ versions of {{book.project.name}} it is planned that you will be able to configu
|
|||
|
||||
==== TOTP Configuration Options
|
||||
|
||||
Hashing Algorithm::
|
||||
OTP Hashing Algorithm::
|
||||
Default is SHA1, more secure options are SHA256 and SHA512.
|
||||
Number of Digits::
|
||||
How many characters is the OTP? Short means more user friendly as it is less the user has to type. More means more security.
|
||||
|
|
@ -43,7 +43,7 @@ OTP Token Period::
|
|||
|
||||
==== HOTP Configuration Options
|
||||
|
||||
Hashing Algorithm::
|
||||
OTP Hashing Algorithm::
|
||||
Default is SHA1, more secure options are SHA256 and SHA512.
|
||||
Number of Digits::
|
||||
How many characters is the OTP? Short means more user friendly as it is less the user has to type. More means more security.
|
||||
|
|
@ -53,5 +53,3 @@ Look Ahead Window::
|
|||
manually too many times by accident. This value really should be increased to a value of 10 or so.
|
||||
Initial Counter::
|
||||
What is the value of the initial counter?
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,11 +37,11 @@ HashAlgorithm::
|
|||
the next time the user logs in.
|
||||
{% endif %}
|
||||
{% if book.product %}
|
||||
HashAlgorithm::
|
||||
Hashing Algorithm::
|
||||
Passwords are not stored as clear text. Instead they are hashed using standard hashing algorithms before they are stored or validated.
|
||||
The only currently supported algorithm is PBKDF2.
|
||||
{% endif %}
|
||||
HashIterations::
|
||||
Hashing Iterations::
|
||||
This value specifies the number of times a password will be hashed before it is stored or verified. The default value is 20,000.
|
||||
This hashing is done in the rare case that a hacker gets access to your password database. Once they have the database
|
||||
they can reverse engineer user passwords.
|
||||
|
|
@ -51,20 +51,18 @@ HashIterations::
|
|||
or protecting your passwords stores. There may be more cost effective ways of protecting your password stores.
|
||||
Digits::
|
||||
How many digits are required to be in the password string?
|
||||
LowerCase::
|
||||
Lowercase Characters::
|
||||
How many lower case letters are required to be in the password string?
|
||||
UpperCase::
|
||||
Uppercase Characters::
|
||||
How many upper case letters are required to be in the password string?
|
||||
SpecialChars::
|
||||
Special Characters::
|
||||
How many special characters like '?!#%$' are required to be in the password string?
|
||||
NotUsername::
|
||||
Not Username::
|
||||
When set, password is not allowed to be the same as the username.
|
||||
RegexPattern::
|
||||
Regular Expression::
|
||||
Define a Perl regular expression pattern that passwords must match.
|
||||
ForceExpiredPasswordChange::
|
||||
Expire Password::
|
||||
How many days is a password valid for? After the number of days has expired, the user will be required to change their password.
|
||||
PasswordHistory::
|
||||
Not Recently Used::
|
||||
This policy saves a history of previous passwords. The number of old passwords stored is configurable. When a user changes their password
|
||||
they will not be able to re-use any password stored in history.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,21 +3,21 @@
|
|||
=== Service Accounts
|
||||
|
||||
Each OIDC client has a built in _service account_ which allows it to obtain an access token.
|
||||
This is covered in the OAuth 2.0 specifiation under <<fake/../../../sso-protocols/oidc.adoc#_client_credentials_grant,Client Credentials Grant>>
|
||||
This is covered in the OAuth 2.0 specifiation under <<fake/../../../sso-protocols/oidc.adoc#_client_credentials_grant,Client Credentials Grant>>.
|
||||
To use this feature you must set the <<fake/../../../clients/client-oidc.adoc#_access-type, Access Type>> of your client to `confidential`. When you do this,
|
||||
the `Service Accounts Enabled` switch will appear. You need to turn on this switch. Also make sure that you have
|
||||
configured your <<fake/../../../clients/oidc/confidential.adoc#_client-credentials, client credentials>>.
|
||||
|
||||
To use it you must have registered a valid `confidential` Client and you need to check the switch `Service Accounts Enabled` in {{book.project.name}} admin console for this client.
|
||||
In tab `Service Account Roles` you can configure the roles available to the service account retrieved on behalf of this client.
|
||||
Don't forget that you need those roles to be available in Scopes of this client as well (unless you have `Full Scope Allowed` on). As in normal login, roles from access token are the intersection of scopes and the service account roles.
|
||||
Don't forget that you need those roles to be available in Scopes of this client as well (unless you have `Full Scope Allowed` on). As in normal login, roles from access token are the intersection of scopes and the service account roles.
|
||||
|
||||
The REST URL to invoke on is `/\{server-root-usualy-auth}/realms/\{realm-name}/protocol/openid-connect/token`.
|
||||
Invoking on this URL is a POST request and requires you to post the client credentials.
|
||||
By default, client credentials are represented by clientId and clientSecret of the client in `Authorization: Basic` header, but you can also authenticate the client with a signed JWT assertion or any other custom mechanism for client authentication.
|
||||
You also need to use the parameter `grant_type=client_credentials` as per the OAuth2 specification.
|
||||
|
||||
For example the POST invocation to retrieve a service account can look like this:
|
||||
For example the POST invocation to retrieve a service account can look like this:
|
||||
|
||||
[source]
|
||||
----
|
||||
|
|
@ -27,8 +27,8 @@ For example the POST invocation to retrieve a service account can look like this
|
|||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
grant_type=client_credentials
|
||||
----
|
||||
The response would be this http://tools.ietf.org/html/rfc6749#section-4.4.3[standard JSON document] from the OAuth 2.0 specification.
|
||||
----
|
||||
The response would be this http://tools.ietf.org/html/rfc6749#section-4.4.3[standard JSON document] from the OAuth 2.0 specification.
|
||||
|
||||
[source]
|
||||
----
|
||||
|
|
@ -48,6 +48,6 @@ Pragma: no-cache
|
|||
"not-before-policy":0,
|
||||
"session_state":"234234-234234-234234"
|
||||
}
|
||||
----
|
||||
----
|
||||
|
||||
The retrieved access token can be refreshed or logged out by an out-of-bound request.
|
||||
The retrieved access token can be refreshed or logged out by an out-of-bound request.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ image:../../{{book.images}}/mapper-config.png[]
|
|||
The best way to learn about a config option is to hover over its tooltip. There are a few config options that
|
||||
are common to all mappers:
|
||||
|
||||
Consent::
|
||||
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.
|
||||
|
|
@ -47,4 +47,3 @@ image:../../{{book.images}}/add-mapper.png[]
|
|||
|
||||
Pick a `Mapper Type` from the list box. If you hover over the tooltip, you'll see a description of what that mapper type does.
|
||||
Different config parameters will appear for different mapper types.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,16 +9,16 @@ is triggered at server boot time and its parameters are passed in via Java syst
|
|||
It is important to note that because import and export happens at server startup, no other actions should be taken on the server
|
||||
or the database while this happens.
|
||||
|
||||
You can export/import your database either to:
|
||||
You can export/import your database either to:
|
||||
|
||||
* Directory on local filesystem
|
||||
* Single JSON file on your filesystem
|
||||
|
||||
When importing using the directory strategy, note that the files need to follow the naming convention specified below.
|
||||
If you are importing files which were previously exported, the files already follow this convention.
|
||||
If you are importing files which were previously exported, the files already follow this convention.
|
||||
|
||||
* {REALM_NAME}-realm.json, such as "acme-roadrunner-affairs-realm.json" for the realm named "acme-roadrunner-affairs"
|
||||
* {REALM_NAME}-users-{INDEX}.json, such as "acme-roadrunner-affairs-users-0.json" for the first users file of the realm named "acme-roadrunner-affairs"
|
||||
* {REALM_NAME}-users-{INDEX}.json, such as "acme-roadrunner-affairs-users-0.json" for the first users file of the realm named "acme-roadrunner-affairs"
|
||||
|
||||
If you export to a directory, you can also specify the number of users that will be stored in each JSON file.
|
||||
|
||||
|
|
@ -28,36 +28,36 @@ NOTE: If you have bigger amount of users in your database (500 or more), it's hi
|
|||
Default count of users per file (and transaction) is 50, which showed us best performance, but you have possibility to override (See below).
|
||||
Exporting to single file is using one transaction per whole export and one per whole import, which results in bad performance with large amount of users.
|
||||
|
||||
To export into unencrypted directory you can use:
|
||||
To export into unencrypted directory you can use:
|
||||
|
||||
[source]
|
||||
----
|
||||
|
||||
bin/standalone.sh -Dkeycloak.migration.action=export
|
||||
-Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=<DIR TO EXPORT TO>
|
||||
----
|
||||
And similarly for import just use `-Dkeycloak.migration.action=import` instead of `export` .
|
||||
To export into single JSON file you can use:
|
||||
----
|
||||
And similarly for import just use `-Dkeycloak.migration.action=import` instead of `export` .
|
||||
To export into single JSON file you can use:
|
||||
|
||||
[source]
|
||||
----
|
||||
bin/standalone.sh -Dkeycloak.migration.action=export
|
||||
-Dkeycloak.migration.provider=singleFile -Dkeycloak.migration.file=<FILE TO EXPORT TO>
|
||||
----
|
||||
Here's an example of importing:
|
||||
----
|
||||
Here's an example of importing:
|
||||
|
||||
[source]
|
||||
----
|
||||
bin/standalone.sh -Dkeycloak.migration.action=import
|
||||
-Dkeycloak.migration.provider=singleFile -Dkeycloak.migration.file=<FILE TO IMPORT>
|
||||
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING
|
||||
----
|
||||
----
|
||||
|
||||
Other available options are:
|
||||
Other available options are:
|
||||
|
||||
-Dkeycloak.migration.realmName::
|
||||
This property is used if you want to export just one specified realm instead of all.
|
||||
If not specified, then all realms will be exported.
|
||||
If not specified, then all realms will be exported.
|
||||
|
||||
-Dkeycloak.migration.usersExportStrategy::
|
||||
This property is used to specify where users are exported.
|
||||
|
|
@ -65,11 +65,11 @@ Other available options are:
|
|||
* DIFFERENT_FILES - Users will be exported into different files according to the maximum number of users per file. This is default value.
|
||||
* SKIP - Exporting of users will be skipped completely.
|
||||
* REALM_FILE - All users will be exported to same file with the realm settings. (The result will be a file like "foo-realm.json" with both realm data and users.)
|
||||
* SAME_FILE - All users will be exported to same file but different from the realm file. (The result will be a file like "foo-realm.json" with realm data and "foo-users.json" with users.)
|
||||
* SAME_FILE - All users will be exported to same file but different from the realm file. (The result will be a file like "foo-realm.json" with realm data and "foo-users.json" with users.)
|
||||
|
||||
-Dkeycloak.migration.usersPerFile::
|
||||
This property is used to specify the number of users per file (and also per DB transaction). It's 50 by default.
|
||||
It's used only if usersExportStrategy is DIFFERENT_FILES
|
||||
It's used only if usersExportStrategy is DIFFERENT_FILES
|
||||
|
||||
-Dkeycloak.migration.strategy::
|
||||
This property is used during import.
|
||||
|
|
@ -83,19 +83,19 @@ Other available options are:
|
|||
When importing realm files that weren't exported before, the option `keycloak.import` can be used.
|
||||
If more than one realm file needs to be imported, a comma separated list of file names can be specified.
|
||||
This is more appropriate than the cases before, as this will happen only after the master realm has been initialized.
|
||||
Examples:
|
||||
Examples:
|
||||
|
||||
* -Dkeycloak.import=/tmp/realm1.json
|
||||
* -Dkeycloak.import=/tmp/realm1.json,/tmp/realm2.json
|
||||
* -Dkeycloak.import=/tmp/realm1.json,/tmp/realm2.json
|
||||
|
||||
=== Admin console export/import
|
||||
|
||||
Import of most resources can be performed from the admin console.
|
||||
Exporting resources will be supported in future versions.
|
||||
Exporting resources will be supported in future versions.
|
||||
|
||||
The files created during a "startup" export can be used to import from the admin UI.
|
||||
This way, you can export from one realm and import to another realm.
|
||||
Or, you can export from one server and import to another.
|
||||
This way, you can export from one realm and import to another realm. Note: The admin console import allows just one realm per file.
|
||||
Or, you can export from one server and import to another.
|
||||
|
||||
WARNING: The admin console import allows you to "overwrite" resources if you choose.
|
||||
Use this feature with caution, especially on a production system.
|
||||
Use this feature with caution, especially on a production system.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ In order to create an identity provider click the `Identity Providers` left menu
|
|||
.Identity Providers
|
||||
image:../../{{book.images}}/identity-providers.png[]
|
||||
|
||||
In the right hand drop down list box, choose the identity provider you want to add. This will bring you to the
|
||||
In the drop down list box, choose the identity provider you want to add. This will bring you to the
|
||||
configuration page for that identity provider type.
|
||||
|
||||
.Add Identity Provider
|
||||
|
|
@ -36,7 +36,7 @@ Protocol-based::
|
|||
It makes it easy to configure and broker any identity provider based on these open standards.
|
||||
|
||||
Although each type of identity provider has its own configuration options, all of them share some very common configuration.
|
||||
Regardless the identity provider you are creating, you'll see the following configuration options avaivable:
|
||||
Regardless the identity provider you are creating, you'll see the following configuration options available:
|
||||
|
||||
.Common Configuration
|
||||
[cols="1,1", options="header"]
|
||||
|
|
@ -73,5 +73,3 @@ Regardless the identity provider you are creating, you'll see the following conf
|
|||
|Post Login Flow
|
||||
|Authentication flow that is triggered after the user finishes logging in with the external identity provider.
|
||||
|===
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ was compromised, it is obviously good to update your keys, but it's also good to
|
|||
<<fake/../../realms/cache.adoc#_clear-cache, Clearing the cache>> section for more details.
|
||||
|
||||
|Use JWKS URL
|
||||
|Applicable just `Validate Signatures` is on. If the switch is on, then identity provider public keys will be downloaded from given JWKS URL.
|
||||
|Applicable if `Validate Signatures` is on. If the switch is on, then identity provider public keys will be downloaded from given JWKS URL.
|
||||
This allows great flexibility because new keys will be always re-downloaded again when identity provider generates new keypair. If the switch is off,
|
||||
then public key (or certificate) from the {{book.project.name}} DB is used, so when identity provider keypair changes, you always need to import new key to the {{book.project.name}} DB as well.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ roles::
|
|||
user role mapping::
|
||||
A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This
|
||||
role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on
|
||||
various resources they manage
|
||||
various resources they manage.
|
||||
composite roles::
|
||||
A composite role is a role that can be associated with other roles. For example a `superuser` composite role could be associated with the
|
||||
`sales-admin` and `order-entry-admin` roles. If a user is mapped to the `superuser` role they also inherit the `sales-admin` and `order-entry-admin` roles.
|
||||
|
|
@ -44,7 +44,7 @@ consent::
|
|||
information is requested of the user. User can decide whether or not to grant the request.
|
||||
client templates::
|
||||
When a client is registered you need to enter configuration information about that client. It is often useful to store a template
|
||||
of this to make create new clients easier. {{book.project.name}} provides the concept of a client template for this.
|
||||
to make create new clients easier. {{book.project.name}} provides the concept of a client template for this.
|
||||
client role::
|
||||
Clients can define roles that are specific to them. This is basically a role namespace dedicated to the client.
|
||||
identity token::
|
||||
|
|
@ -88,4 +88,4 @@ authentication flows::
|
|||
events::
|
||||
Events are audit streams that admins can view and hook into.
|
||||
themes::
|
||||
Every screen provided by {{book.project.name}} is backed by a theme. Themes define HTML templates and stylesheets which you can override as needed.
|
||||
Every screen provided by {{book.project.name}} is backed by a theme. Themes define HTML templates and stylesheets which you can override as needed.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
=== Features
|
||||
|
||||
* Single-Sign On and Single-Sign Out for browser applications
|
||||
* Single-Sign On and Single-Sign Out for browser applications.
|
||||
* OpenID Connect support.
|
||||
* OAuth 2.0 support.
|
||||
* SAML support.
|
||||
|
|
@ -12,12 +12,12 @@
|
|||
* Admin Console for central management of users, roles, role mappings, clients and configuration.
|
||||
* Account Management console that allows users to centrally manage their account.
|
||||
* Theme support - Customize all user facing pages to integrate with your applications and branding.
|
||||
* Two-factor Authentication - Support for TOTP/HOTP via Google Authenticator or FreeOTP
|
||||
* Two-factor Authentication - Support for TOTP/HOTP via Google Authenticator or FreeOTP.
|
||||
* Login flows - optional user self-registration, recover password, verify email, require password update, etc.
|
||||
* Session management - Admins and users themselves can view and manage user sessions.
|
||||
* Token mappers - Map user attributes, roles, etc. how you want into tokens and statements.
|
||||
* Not-before revocation policies per realm, application and user.
|
||||
* CORS support - Client adapters have built-in support for CORS
|
||||
* CORS support - Client adapters have built-in support for CORS.
|
||||
{% if book.community %}
|
||||
* Service Provider Interfaces (SPI) - A number of SPIs to enable customizing various aspects of the server. Authentication flows, user federation providers,
|
||||
protocol mappers and many more.
|
||||
|
|
@ -26,4 +26,4 @@ protocol mappers and many more.
|
|||
{% if book.product %}
|
||||
* Client adapters for JavaScript applications, JBoss EAP, Fuse, etc.
|
||||
{% endif %}
|
||||
* Supports any platform/language that has an OpenID Connect Resource Provider library or SAML 2.0 Service Provider library
|
||||
* Supports any platform/language that has an OpenID Connect Resource Provider library or SAML 2.0 Service Provider library.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ there's a chance parts of the in-memory cache may be stale. You can clear the r
|
|||
external clients or Identity providers, which {{book.project.name}} usually uses for verify signatures of particular external entity) from the Admin Console by going
|
||||
to the `Realm Settings` left menu item and the `Cache` tab.
|
||||
|
||||
.Keys tab
|
||||
.Cache tab
|
||||
image:../../{{book.images}}/cache-tab.png[]
|
||||
|
||||
Just click the `clear` button on the cache you want to evict.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ is only one active keypair. In the future as more signature algorithms are added
|
|||
|
||||
To view all available keys select `All`. This will show all active, passive and disabled keys. A keypair can have the
|
||||
status `Active`, but still not be selected as the currently active keypair for the realm. The selected active pair which
|
||||
is used for signatures is selected based on the the first key provider sorted by priority that is able to provide an
|
||||
is used for signatures is selected based on the first key provider sorted by priority that is able to provide an
|
||||
active keypair.
|
||||
|
||||
==== Rotating keys
|
||||
|
|
@ -50,7 +50,7 @@ Click `Save` to add the new keys. This will generated a new keypair including a
|
|||
Changing the priority for a provider will not cause the keys to be re-generated, but if you want to change the keysize
|
||||
you can edit the provider and new keys will be generated.
|
||||
|
||||
==== Adding a existing keypair and certificate
|
||||
==== Adding an existing keypair and certificate
|
||||
|
||||
To add a keypair and certificate obtained elsewhere select `Providers` and choose `rsa` from the dropdown. You can change
|
||||
the priority to make sure the new keypair becomes the active keypair.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,5 @@ none::
|
|||
{{book.project.name}} does not require SSL. This should really only be used in development when you are playing around with things and don't want to bother
|
||||
configuring SSL on your server.
|
||||
|
||||
all::
|
||||
all requests::
|
||||
{{book.project.name}} requires SSL for all IP addresses.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -71,11 +71,11 @@ Here's a brief summary of the protocol:
|
|||
. {{book.project.name}} authenticates the user and creates an _identity_ and _access_ token. {{book.project.name}}
|
||||
redirects back to the application using the callback URL provided earlier and additionally adding the _identity_ and
|
||||
_access_ tokens as query parameters in the callback URL.
|
||||
. The application extracts the the _identity_ and _access_ tokens from the callback URL.
|
||||
. The application extracts the _identity_ and _access_ tokens from the callback URL.
|
||||
|
||||
===== Resource Owner Password Credentials Grant (Direct Grants)
|
||||
===== Resource Owner Password Credentials Grant (Direct Access Grants)
|
||||
|
||||
This is referred to in the Admin Console as _Direct Grants_. This is used by REST clients that want to obtain a token on behalf of a user. It is one HTTP POST request that contains
|
||||
This is referred to in the Admin Console as _Direct Access Grants_. This is used by REST clients that want to obtain a token on behalf of a user. It is one HTTP POST request that contains
|
||||
the credentials of the user as well as the id of the client and the client's secret (if it is a confidential client). The user's credentials
|
||||
are sent within form parameters. The HTTP response contains
|
||||
_identity_, _access_, and _refresh_ tokens.
|
||||
|
|
@ -103,4 +103,3 @@ _/auth_: i.e. $$https://localhost:8080/auth$$
|
|||
This is the URL endpoint for the User Info service described in the OIDC specification.
|
||||
|
||||
In all of these replace _\{realm-name}_ with the name of the realm.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ If the `Temporary` switch is on, this new password can only be used once and the
|
|||
logged in.
|
||||
|
||||
Alternatively, if you have <<fake/../../realms/email.adoc#_email, email>> set up, you can send an email to the user that asks
|
||||
them to reset their password. Choose `Update Password` from the `Reset Actions` list box and click the `Reset Actions Email`.
|
||||
them to reset their password. Choose `Update Password` from the `Reset Actions` list box and click the `Send Email`.
|
||||
The sent email contains a link that will bring the user to the update password screen.
|
||||
|
||||
==== Changing OTPs
|
||||
|
|
@ -26,4 +26,4 @@ OTP generator. If OTP is required, then the user will be asked to re-configure a
|
|||
|
||||
Like passwords, you can alternatively send an email to the user that will ask them to reset their OTP generator. Choose
|
||||
`Configure OTP` in the `Reset Actions` list box and click the `Send Email` button. The sent email
|
||||
contains a link that will bring the user to the OTP setup screen.
|
||||
contains a link that will bring the user to the OTP setup screen.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
To safeguard registration against bots, {{book.project.name}} has integration with Google reCAPTCHA.
|
||||
To enable this you need to first go to link:https://developers.google.com/recaptcha/[Google Recaptcha Website]
|
||||
and create an API key so that you can get your reCAPTCHA site key and secret.
|
||||
(FYI, localhost works by default so you don't have to specify a domain).
|
||||
(FYI, localhost works by default so you don't have to specify a domain).
|
||||
|
||||
Next, there are a few steps you need to perform in the {{book.project.name}} Admin Console.
|
||||
Click the `Authentication` left menu item and go to the `Flows` tab. Select the `Registration` flow from the drop down
|
||||
|
|
@ -17,7 +17,7 @@ image:../../{{book.images}}/registration-flow.png[]
|
|||
|
||||
Set the 'reCAPTCHA' requirement to `Required` by clicking the appropriate radio button. This will enable
|
||||
reCAPTCHA on the screen. Next, you have to enter in the reCAPTCHA site key and secret that you generated at the Google reCAPTCHA Website.
|
||||
Click on the 'Configure' button that is to the right of the reCAPTCHA flow entry and enter in the reCAPTCHA site key and secret on this config page.
|
||||
Click on the 'Actions' button that is to the right of the reCAPTCHA flow entry, then "Config" link, and enter in the reCAPTCHA site key and secret on this config page.
|
||||
|
||||
.Recaptcha Config Page
|
||||
image:../../{{book.images}}/recaptcha-config.png[]
|
||||
|
|
|
|||
Loading…
Reference in a new issue