Applying official TOC
This commit is contained in:
parent
3326ed1630
commit
ef1bf867f4
13 changed files with 19 additions and 19 deletions
|
@ -111,7 +111,7 @@ You can view the devices that are logged in to your account.
|
|||
.Procedure
|
||||
|
||||
. Click *Account Security* in the menu.
|
||||
. Click *Device Activity*.
|
||||
. Click *Device Activity*.
|
||||
. Log out a device if it looks suspicious.
|
||||
|
||||
.Devices
|
||||
|
@ -135,7 +135,7 @@ You can link your account with an <<_identity_broker, identity broker>>. This op
|
|||
|
||||
. Click *Account Security* in the menu.
|
||||
|
||||
. Click *Linked Accounts*.
|
||||
. Click *Linked Accounts*.
|
||||
|
||||
The identity provider you added appears in this page.
|
||||
|
||||
|
@ -148,4 +148,3 @@ The *Applications* menu item shows users which applications you can access. In t
|
|||
|
||||
.Applications
|
||||
image:images/account-console-applications.png[Applications]
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
== The Admin CLI
|
||||
== Admin CLI
|
||||
|
||||
In previous chapters, we described how to use the {project_name} Admin Console to perform administrative tasks. You can also perform those tasks from the command-line interface (CLI) by using the Admin CLI command-line tool.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[[_admin_permissions]]
|
||||
|
||||
== Controlling Access to the Admin Console
|
||||
== Controlling access to the Admin Console
|
||||
|
||||
Each realm created on the {project_name} has a dedicated Admin Console from which that realm can be managed.
|
||||
The `master` realm is a special realm that allows admins to manage more than one realm on the system. You can also
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
[id="assembly-managing-clients_{context}"]
|
||||
== Managing Clients
|
||||
== Managing OpenID Connect and SAML Clients
|
||||
|
||||
[role="_abstract"]
|
||||
Clients are entities that can request authentication of a user. Clients come in two forms.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
[id="assembly-managing-users_{context}"]
|
||||
== Managing Users
|
||||
== Managing users
|
||||
|
||||
From the Admin Console, you have a wide range of actions you can perform to manage users.
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
== Auditing and Events
|
||||
== Configuring auditing to track events
|
||||
|
||||
{project_name} provides a rich set of auditing capabilities. Every single login action can be recorded and stored in
|
||||
the database and reviewed in the Admin Console. All admin actions can also be recorded and reviewed. There is also a Listener SPI
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
[id=assembly-exporting-importing_{context}]
|
||||
== Export and Import
|
||||
== Exporting and import the database
|
||||
|
||||
{project_name} has the ability to export and import the entire database.
|
||||
This can be especially useful if you want to migrate your whole {project_name} database from one environment to another or migrate to a different database (for example from MySQL to Oracle). Export and import is triggered at server boot time and its parameters are passed in via Java system properties.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
[[_identity_broker]]
|
||||
== Identity Brokering
|
||||
== Integrating identity providers
|
||||
|
||||
An Identity Broker is an intermediary service that connects multiple service providers with different identity providers.
|
||||
As an intermediary service, the identity broker is responsible for creating
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
== User Session Management
|
||||
== Managing user sessions
|
||||
|
||||
When users log into realms, {project_name} maintains a user session for each user and remembers each client visited by the user within the session. Realm administrators can perform multiple actions on each user session:
|
||||
|
||||
|
|
|
@ -6,3 +6,4 @@
|
|||
You can conduct transient sessions in {project_name}. When using transient sessions, {project_name} does not create a user session after successful authentication. {project_name} creates a temporary, transient session for the scope of the current request that successfully authenticates the user. {project_name} can run <<_protocol-mappers, protocol mappers>> using transient sessions after authentication.
|
||||
|
||||
During transient sessions, the client application cannot refresh tokens, introspect tokens, or validate a specific session. Sometimes these actions are unnecessary, so you can avoid the additional resource use of persisting user sessions. This session saves performance, memory, and network communication (in cluster and cross-data center environments) resources.
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
== Mitigating Security threats
|
||||
== Mitigating security threats
|
||||
|
||||
Security vulnerabilities exist in any authentication server. See the Internet Engineering Task Force's (IETF) https://tools.ietf.org/html/rfc6819[OAuth 2.0 Threat Model] and the https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15[OAuth 2.0 Security Best Current Practice] for more information.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[[_user-storage-federation]]
|
||||
|
||||
== User Storage Federation
|
||||
== Using external storage
|
||||
|
||||
Many companies have existing user databases that hold information about users and their passwords or other credentials.
|
||||
In many cases, it is just not possible to migrate off of those existing stores to a pure {project_name} deployment.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
[[_vault-administration]]
|
||||
|
||||
== Using a Vault to Obtain Secrets
|
||||
== Using a vault to obtain secrets
|
||||
|
||||
To obtain a secret from a vault rather than entering it directly, enter the following specially crafted string into the appropriate field:
|
||||
|
||||
|
@ -133,7 +133,7 @@ All built-in providers support the configuration of key resolvers. A key resolve
|
|||
</spi>
|
||||
----
|
||||
|
||||
The resolvers run in the same order you declare them in the configuration. For each resolver, {project_name} uses the last entry name the resolver produces, which combines the realm with the vault key to search for the vault's secret. If {project_name} finds a secret, it returns the secret. If not, {project_name} uses the next resolver. This search continues until {project_name} finds a non-empty secret or runs out of resolvers. If {project_name} finds no secret, {project_name} returns an empty secret.
|
||||
The resolvers run in the same order you declare them in the configuration. For each resolver, {project_name} uses the last entry name the resolver produces, which combines the realm with the vault key to search for the vault's secret. If {project_name} finds a secret, it returns the secret. If not, {project_name} uses the next resolver. This search continues until {project_name} finds a non-empty secret or runs out of resolvers. If {project_name} finds no secret, {project_name} returns an empty secret.
|
||||
|
||||
In the previous example, {project_name} uses the `REALM_UNDERSCORE_KEY` resolver first. If {project_name} finds an entry in the vault that using that resolver, {project_name} returns that entry. If not, {project_name} searches again using the `KEY_ONLY` resolver. If {project_name} finds an entry by using the `KEY_ONLY` resolver, {project_name} returns that entry. If {project_name} uses all resolvers, {project_name} returns an empty secret.
|
||||
|
||||
|
@ -223,7 +223,7 @@ You create the credential store and a vault where the credential store and vault
|
|||
|
||||
.Prerequisites
|
||||
|
||||
* A running LDAP instance has `BIND DN credential: secret12`.
|
||||
* A running LDAP instance has `BIND DN credential: secret12`.
|
||||
|
||||
* The alias uses the format <realm-name>_< key-value> when using the default key resolver. In this case, the instance is running in the realm `ldaptest` and `ldaptest_ldap_secret` is the alias that corresponds to the value `ldap_secret` in that realm.
|
||||
|
||||
|
@ -238,7 +238,7 @@ NOTE: The resolver replaces underscore characters with double underscore charact
|
|||
[standalone@localhost:9990 /] /subsystem=elytron/credential-store=test-store:add(create=true, location=/home/test/test-store.p12, credential-reference={clear-text=testpwd1!},implementation-properties={keyStoreType=PKCS12})
|
||||
----
|
||||
|
||||
. Add an alias to the credential store.
|
||||
. Add an alias to the credential store.
|
||||
|
||||
+
|
||||
[source,bash,subs=+attributes]
|
||||
|
@ -258,7 +258,7 @@ Keystore provider: SUN
|
|||
|
||||
Your keystore contains 1 entries
|
||||
|
||||
ldaptest_ldap__secret/passwordcredential/clear/, Oct 12, 2020, SecretKeyEntry,
|
||||
ldaptest_ldap__secret/passwordcredential/clear/, Oct 12, 2020, SecretKeyEntry,
|
||||
----
|
||||
|
||||
. Configure the vault SPI in {project_name}.
|
||||
|
@ -329,7 +329,7 @@ MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123
|
|||
/subsystem=elytron/credential-store=cs-store:write-attribute(name=credential-reference.clear-text,value="MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123")
|
||||
----
|
||||
|
||||
. Update the {project_name} vault configuration to use the masked password.
|
||||
. Update the {project_name} vault configuration to use the masked password.
|
||||
+
|
||||
[source,bash,subs=+attributes]
|
||||
----
|
||||
|
|
Loading…
Reference in a new issue