moving content from master to admin-reuse
This commit is contained in:
parent
59f8d09294
commit
3076ab2f2f
16 changed files with 248 additions and 37 deletions
|
@ -11,12 +11,12 @@ include::topics/realms/cache.adoc[]
|
||||||
include::topics/realms/email.adoc[]
|
include::topics/realms/email.adoc[]
|
||||||
include::topics/realms/themes.adoc[]
|
include::topics/realms/themes.adoc[]
|
||||||
include::topics/users.adoc[]
|
include::topics/users.adoc[]
|
||||||
include::topics/users/viewing.adoc[]
|
include::topics/users/proc-searching-user.adoc[leveloffset=+1]
|
||||||
include::topics/users/create-user.adoc[]
|
include::topics/users/proc-creating-user.adoc[leveloffset=+1]
|
||||||
include::topics/users/delete-user.adoc[]
|
include::topics/users/proc-deleting-user.adoc[leveloffset=+1]
|
||||||
include::topics/users/attributes.adoc[]
|
include::topics/users/proc-configuring-user-attributes.adoc[leveloffset=+1]
|
||||||
include::topics/users/credentials.adoc[]
|
include::topics/users/credentials.adoc[leveloffset=+1]
|
||||||
include::topics/users/required-actions.adoc[]
|
include::topics/users/con-required-actions.adoc[leveloffset=+1]
|
||||||
include::topics/users/impersonation.adoc[]
|
include::topics/users/impersonation.adoc[]
|
||||||
include::topics/users/user-registration.adoc[]
|
include::topics/users/user-registration.adoc[]
|
||||||
include::topics/users/recaptcha.adoc[]
|
include::topics/users/recaptcha.adoc[]
|
||||||
|
@ -42,7 +42,7 @@ include::topics/sso-protocols/docker.adoc[]
|
||||||
include::topics/clients.adoc[]
|
include::topics/clients.adoc[]
|
||||||
include::topics/clients/client-oidc.adoc[]
|
include::topics/clients/client-oidc.adoc[]
|
||||||
include::topics/clients/oidc/con-confidential-client-credentials.adoc[]
|
include::topics/clients/oidc/con-confidential-client-credentials.adoc[]
|
||||||
include::topics/clients/oidc/service-accounts.adoc[]
|
include::topics/clients/oidc/proc-using-a-service-account.adoc[]
|
||||||
include::topics/clients/oidc/audience.adoc[]
|
include::topics/clients/oidc/audience.adoc[]
|
||||||
include::topics/clients/client-saml.adoc[]
|
include::topics/clients/client-saml.adoc[]
|
||||||
include::topics/clients/saml/idp-initiated-login.adoc[]
|
include::topics/clients/saml/idp-initiated-login.adoc[]
|
||||||
|
|
|
@ -17,6 +17,9 @@ This choice is the default setting. The secret is automatically generated for yo
|
||||||
|
|
||||||
*Signed JWT*
|
*Signed JWT*
|
||||||
|
|
||||||
|
.Signed JWT
|
||||||
|
image:{project_images}/client-credentials-jwt.png[]
|
||||||
|
|
||||||
`Signed JWT` is "Signed Json Web Token".
|
`Signed JWT` is "Signed Json Web Token".
|
||||||
|
|
||||||
To use the `Signed JWT` credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click the `Generate new keys and certificate` button to begin this process.
|
To use the `Signed JWT` credential type, a private key and certificate must be generated for the client. The private key is used to sign the JWT and the certificate is used by the server to verify the signature. Click the `Generate new keys and certificate` button to begin this process.
|
||||||
|
|
|
@ -0,0 +1,65 @@
|
||||||
|
|
||||||
|
[[_service_accounts]]
|
||||||
|
==== Using a Service Account
|
||||||
|
|
||||||
|
Each OIDC client has a built-in _service account_, which allows it to obtain an access token.
|
||||||
|
|
||||||
|
.Prerequisites
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Select your client in {project_name}.
|
||||||
|
. Click on the `Settings` tab.
|
||||||
|
. Set the <<_access-type, Access Type>> of your client is set to `confidential`.
|
||||||
|
. Set the `Service Accounts Enabled` switch to ON.
|
||||||
|
. Click *Save*.
|
||||||
|
. Configure your <<_client-credentials, client credentials>>.
|
||||||
|
. Click on the `Scope` tab.
|
||||||
|
. Verify that you have roles or set Full Scope Allowed to ON.
|
||||||
|
. On the `Service Account Roles` tab, configure the roles available to this service account for your client.
|
||||||
|
|
||||||
|
Roles from access tokens are the intersection of:
|
||||||
|
|
||||||
|
* Role scope mappings of a client combined with the role scope mappings inherited from linked client scopes.
|
||||||
|
* Service account roles.
|
||||||
|
|
||||||
|
The REST URL to invoke is `/auth/realms/{realm-name}/protocol/openid-connect/token`. This URL must be invoked as a POST request and requires that you post the client credentials with the request.
|
||||||
|
|
||||||
|
By default, client credentials are represented by the clientId and clientSecret of the client in the `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 set the `grant_type` parameter to "client_credentials" as per the OAuth2 specification.
|
||||||
|
|
||||||
|
For example, the POST invocation to retrieve a service account can look like this:
|
||||||
|
|
||||||
|
[source]
|
||||||
|
----
|
||||||
|
|
||||||
|
POST /auth/realms/demo/protocol/openid-connect/token
|
||||||
|
Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
|
||||||
|
Content-Type: application/x-www-form-urlencoded
|
||||||
|
|
||||||
|
grant_type=client_credentials
|
||||||
|
----
|
||||||
|
|
||||||
|
The response would be similar to this https://tools.ietf.org/html/rfc6749#section-4.4.3[Access Token Response] from the OAuth 2.0 specification.
|
||||||
|
|
||||||
|
[source]
|
||||||
|
----
|
||||||
|
|
||||||
|
HTTP/1.1 200 OK
|
||||||
|
Content-Type: application/json;charset=UTF-8
|
||||||
|
Cache-Control: no-store
|
||||||
|
Pragma: no-cache
|
||||||
|
|
||||||
|
{
|
||||||
|
"access_token":"2YotnFZFEjr1zCsicMWpAA",
|
||||||
|
"token_type":"bearer",
|
||||||
|
"expires_in":60,
|
||||||
|
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
|
||||||
|
"refresh_expires_in":600,
|
||||||
|
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
|
||||||
|
"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.
|
25
server_admin/topics/users/con-required-actions.adoc
Normal file
25
server_admin/topics/users/con-required-actions.adoc
Normal file
|
@ -0,0 +1,25 @@
|
||||||
|
[id="con-required-actions_{context}"]
|
||||||
|
== Required Actions
|
||||||
|
|
||||||
|
A user must complete required actions before initially logging in. A user must provide credentials before required actions can be executed. Once a required action is completed, the user does not have to perform the action again.
|
||||||
|
|
||||||
|
Admins can add required actions for each user, in the *Details* tab of the admin console.
|
||||||
|
|
||||||
|
The following are examples of required action types:
|
||||||
|
|
||||||
|
Update Password::
|
||||||
|
The user must change their password.
|
||||||
|
|
||||||
|
Configure OTP::
|
||||||
|
The user must configure a one-time password generator on their mobile device using either the Free OTP or Google Authenticator application.
|
||||||
|
|
||||||
|
Verify Email::
|
||||||
|
The user must verify their email account. An email will be sent to the user with a validation link that they must click. Once this workflow is successfully completed, the user will be allowed to log in.
|
||||||
|
|
||||||
|
Update Profile::
|
||||||
|
The user must update profile information, such as name, address, email, and phone number.
|
||||||
|
|
||||||
|
|
||||||
|
include::proc-setting-required-actions.adoc[]
|
||||||
|
include::proc-setting-default-required-actions.adoc[]
|
||||||
|
include::proc-enabling-terms-conditions.adoc[]
|
|
@ -1,7 +1,5 @@
|
||||||
|
|
||||||
|
|
||||||
[[_user-credentials]]
|
[[_user-credentials]]
|
||||||
=== User Credentials
|
== User Credentials
|
||||||
|
|
||||||
When viewing a user if you go to the `Credentials` tab you can manage a user's credentials.
|
When viewing a user if you go to the `Credentials` tab you can manage a user's credentials.
|
||||||
|
|
||||||
|
@ -25,7 +23,7 @@ Data::
|
||||||
Actions::
|
Actions::
|
||||||
This column has two buttons. `Save` records the value of the User Label, while `Delete` will remove the credential.
|
This column has two buttons. `Save` records the value of the User Label, while `Delete` will remove the credential.
|
||||||
|
|
||||||
==== Creating a Password for the User
|
=== Creating a Password for the User
|
||||||
|
|
||||||
If a user doesn't have a password, or if the password has been deleted, the `Set Password` section will be shown on the page.
|
If a user doesn't have a password, or if the password has been deleted, the `Set Password` section will be shown on the page.
|
||||||
|
|
||||||
|
@ -45,16 +43,15 @@ The sent email contains a link that will bring the user to the update password s
|
||||||
|
|
||||||
Note that a user can only have a single credential of type password.
|
Note that a user can only have a single credential of type password.
|
||||||
|
|
||||||
==== Creating other credentials
|
=== Creating other credentials
|
||||||
|
|
||||||
You cannot configure other types of credentials for a specific user within the Admin Console. This is the responsibility of the user.
|
You cannot configure other types of credentials for a specific user within the Admin Console. This is the responsibility of the user.
|
||||||
You can only delete credentials for a user on the `Credentials` tab, for example if the user has lost an OTP device, or if a credential
|
You can only delete credentials for a user on the `Credentials` tab, for example if the user has lost an OTP device, or if a credential
|
||||||
has been compromised.
|
has been compromised.
|
||||||
|
|
||||||
===== Creating an OTP
|
=== Creating an OTP
|
||||||
|
|
||||||
If OTP is conditional in your realm, the user will have to go to the User Account Management service to re-configure a new
|
If OTP is conditional in your realm, the user will have to go to the User Account Management service to re-configure a new OTP generator. If OTP is required, then the user will be asked
|
||||||
OTP generator. If OTP is required, then the user will be asked
|
|
||||||
to re-configure a new OTP generator when they log in.
|
to re-configure a new OTP generator when they log in.
|
||||||
|
|
||||||
Like passwords, you can alternatively send an email to the user that will ask them to reset their OTP generator. Choose
|
Like passwords, you can alternatively send an email to the user that will ask them to reset their OTP generator. Choose
|
||||||
|
|
|
@ -1,27 +1,18 @@
|
||||||
|
[id="con-impersonating_{context}"]
|
||||||
=== Impersonation
|
=== Impersonation
|
||||||
|
|
||||||
It is often useful for an admin to impersonate a user. For example, a user may be experiencing a bug in one of your applications and
|
It is often useful for an admin to impersonate a user. For example, a user may be experiencing a bug in one of your applications and an admin may want to impersonate the user to see if they can duplicate the problem. Admins with the appropriate permission can impersonate a user.
|
||||||
an admin may want to impersonate the user to see if they can duplicate the problem. Admins with the appropriate permission
|
|
||||||
can impersonate a user. There are two locations an admin can initiate impersonation. The first is on the `Users` list tab.
|
|
||||||
|
|
||||||
.Users
|
Any user with the `impersonation` role in the realm can impersonate a user.
|
||||||
image:{project_images}/user-search.png[]
|
|
||||||
|
|
||||||
You can see here that the admin has searched for `john`. Next to John's account you can see an impersonate button. Click that
|
|
||||||
to impersonate the user.
|
|
||||||
|
|
||||||
Also, you can impersonate the user from the user `Details` tab.
|
|
||||||
|
|
||||||
.User Details
|
|
||||||
image:{project_images}/user-details.png[]
|
image:{project_images}/user-details.png[]
|
||||||
|
|
||||||
Near the bottom of the page you can see the `Impersonate` button. Click that to impersonate the user.
|
|
||||||
|
|
||||||
When impersonating, if the admin and the user are in the same realm, then the admin will be logged out and automatically logged
|
When impersonating, if the admin and the user are in the same realm, then the admin will be logged out and automatically logged
|
||||||
in as the user being impersonated. If the admin and user are not in the same realm, the admin will remain logged in, but additionally
|
in as the user being impersonated. If the admin and user are not in the same realm, the admin will remain logged in, but additionally be logged in as the user in that user's realm. In both cases, the browser will be redirected to the impersonated user's User Account Management page.
|
||||||
be logged in as the user in that user's realm. In both cases, the browser will be redirected to the impersonated user's User Account Management
|
|
||||||
page.
|
|
||||||
|
|
||||||
Any user with the realm's `impersonation` role can impersonate a user. Please see the <<_admin_permissions,Admin Console Access Control>> chapter
|
|
||||||
for more details on assigning administration permissions.
|
There are two locations an admin can initiate impersonation. The first is on the `Users` list tab.
|
||||||
|
|
||||||
|
|
||||||
|
.Additional resources
|
||||||
|
For more information on assigning administration permissions, see the <<_admin_permissions,Admin Console Access Control>> chapter.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[[_personal_data]]
|
[[_personal_data]]
|
||||||
|
|
||||||
=== Personal data collected by {project_name}
|
== Personal data collected by {project_name}
|
||||||
|
|
||||||
By default, {project_name} collects the following:
|
By default, {project_name} collects the following:
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,19 @@
|
||||||
|
[id="proc-configuring-user-attributes_{context}"]
|
||||||
|
== Configuring user attributes
|
||||||
|
|
||||||
|
User attributes provide a customized experience for each user. Using user attributes, you can can create a personalized identity for each user in the console.
|
||||||
|
|
||||||
|
.Prerequisite
|
||||||
|
* You are in the realm where the user exists.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Click *Users* in the left menu.
|
||||||
|
. Select a user to manage.
|
||||||
|
. Click the *Attributes* tab.
|
||||||
|
. Enter the attribute name in the *Key* field.
|
||||||
|
. Enter the attribute value in the *Value* field.
|
||||||
|
. Click *Add*.
|
||||||
|
. Click *Save*.
|
||||||
|
|
||||||
|
|
||||||
|
|
25
server_admin/topics/users/proc-creating-user.adoc
Normal file
25
server_admin/topics/users/proc-creating-user.adoc
Normal file
|
@ -0,0 +1,25 @@
|
||||||
|
[id="proc-creating-user_{context}"]
|
||||||
|
== Creating a user
|
||||||
|
|
||||||
|
Administrators can create users and applications that are owned by the users of a specified realm. In the console, you can add users and register applications to be secured by {project_name}.
|
||||||
|
|
||||||
|
A user can use the console to access applications in a realm, update profile information, and change credentials.
|
||||||
|
|
||||||
|
Create users in the same realm that contains the applications for the user. Every user in a realm has access to the console and the applications in that realm.
|
||||||
|
|
||||||
|
.Prerequisites
|
||||||
|
* You are not in the master realm. Use the master realm only to create other realms.
|
||||||
|
* You are in the realm that contains the applications for the user.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. In the console, click *Users* in the left menu.
|
||||||
|
. Click *Add User*, located on the right side of the empty user list.
|
||||||
|
. Enter the details for the new user.
|
||||||
|
+
|
||||||
|
NOTE: *Username* is the only required field.
|
||||||
|
+
|
||||||
|
. Click *Save*. After saving the details, the *management page* for the new user is displayed.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
16
server_admin/topics/users/proc-deleting-user.adoc
Normal file
16
server_admin/topics/users/proc-deleting-user.adoc
Normal file
|
@ -0,0 +1,16 @@
|
||||||
|
[id="proc-deleting-user_{context}"]
|
||||||
|
== Deleting a user
|
||||||
|
|
||||||
|
You can delete a user, who no longer needs access to applications in the {project_name} console. If a user is deleted, the user profile and data is also deleted.
|
||||||
|
|
||||||
|
.Prerequisite
|
||||||
|
* You are in the realm where the user exists.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Click on *Users* in the left menu. This opens the user list page.
|
||||||
|
. Click *View all users* to find the user to delete.
|
||||||
|
+
|
||||||
|
NOTE: Alternatively, you can use the search bar to find a user.
|
||||||
|
+
|
||||||
|
. Click *Delete* next to the user you want to remove and confirm deletion.
|
||||||
|
|
|
@ -0,0 +1,12 @@
|
||||||
|
[id="proc-enabling-terms-conditions_{context}"]
|
||||||
|
=== Terms and conditions
|
||||||
|
|
||||||
|
{project_name} requires new users to accept the terms and conditions before logging in for the first time.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Click the *Required Actions* tab.
|
||||||
|
. Enable the *Terms and Conditions* action.
|
||||||
|
. Edit the `terms.ftl` file in the _base_ login theme.
|
||||||
|
|
||||||
|
.Additional resources
|
||||||
|
For more information on extending and creating themes, see the link:{developerguide_link}[{developerguide_name}].
|
24
server_admin/topics/users/proc-searching-user.adoc
Normal file
24
server_admin/topics/users/proc-searching-user.adoc
Normal file
|
@ -0,0 +1,24 @@
|
||||||
|
[id="proc-searching-user_{context}"]
|
||||||
|
=== Searching for a user
|
||||||
|
|
||||||
|
Search for a user to view detailed information about the user's groups and roles.
|
||||||
|
|
||||||
|
.Prerequisite
|
||||||
|
* You are in the realm where the user exists.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Click *Users* in the left menu. This opens the user list page.
|
||||||
|
. Type the full name, last name, first name, or email address of the user you want to search for in the search box. The search returns all users that match your criteria.
|
||||||
|
. Alternatively, you can click *View all users* to list every user in the system.
|
||||||
|
+
|
||||||
|
NOTE: This action searches only the local {project_name} database and not the federated database, such as LDAP. The backends for federated databases do not have a pagination mechanism that enables searching for users.
|
||||||
|
+
|
||||||
|
.. To search users from a federated backend, the user list must be synced into the {project_name} database. Adjust the search criteria to sync the backend users to the {project_name} database.
|
||||||
|
+
|
||||||
|
.. Alternatively, click the *User Federation* tab.
|
||||||
|
... To apply changes to a selected user, click *Sync changed users* on the page with your federation provider.
|
||||||
|
... To apply changes to all users in the database, click *Sync all users* on the page with your federation provider.
|
||||||
|
|
||||||
|
.Additional resources
|
||||||
|
* For more information on user federation, see <<_user-storage-federation,User Federation>>.
|
||||||
|
|
|
@ -0,0 +1,18 @@
|
||||||
|
[id="proc-setting-default-required-actions_{context}"]
|
||||||
|
=== Setting default required actions
|
||||||
|
|
||||||
|
You can use the registration link or the *Required Actions* tab to specify the required actions that must be completed by a user before logging in.
|
||||||
|
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
|
||||||
|
.Using the user registration link
|
||||||
|
. Click *Add User* to navigate to the user list page.
|
||||||
|
. Click the <<_user-registration, user registration>> link on the login page.
|
||||||
|
. Specify the default required actions.
|
||||||
|
|
||||||
|
.Using the Required Actions tab
|
||||||
|
. Click *Authentication* in the left menu.
|
||||||
|
. Click the *Required Actions* tab.
|
||||||
|
. Click the checkbox in the *Default Action* column for one or more required actions. When a new user logs in for the first time, the selected actions must be executed.
|
||||||
|
|
16
server_admin/topics/users/proc-setting-required-actions.adoc
Normal file
16
server_admin/topics/users/proc-setting-required-actions.adoc
Normal file
|
@ -0,0 +1,16 @@
|
||||||
|
[id="proc-setting-required-actions_{context}"]
|
||||||
|
=== Setting required actions
|
||||||
|
|
||||||
|
You can add and remove the required actions for existing users in the admin console.
|
||||||
|
|
||||||
|
image:{project_images}/user-required-action.png[]
|
||||||
|
|
||||||
|
.Prerequisite
|
||||||
|
* You have administrator privileges and are logged into the admin console.
|
||||||
|
|
||||||
|
.Procedure
|
||||||
|
. Navigate to the *Required User Actions* list.
|
||||||
|
. Select all the actions you want to add to the account.
|
||||||
|
. Click the *X* next to the action name to remove it.
|
||||||
|
. Click *Save* after you select which actions to add.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[[_recaptcha]]
|
[[_recaptcha]]
|
||||||
|
|
||||||
==== reCAPTCHA Support
|
=== reCAPTCHA Support
|
||||||
|
|
||||||
To safeguard registration against bots, {project_name} has integration with Google reCAPTCHA.
|
To safeguard registration against bots, {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]
|
To enable this you need to first go to link:https://developers.google.com/recaptcha/[Google Recaptcha Website]
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[[_user-registration]]
|
[[_user-registration]]
|
||||||
|
|
||||||
=== User Registration
|
== User Registration
|
||||||
|
|
||||||
You can enable {project_name} to allow user self registration. When enabled, the login page has a registration
|
You can enable {project_name} to allow user self registration. When enabled, the login page has a registration
|
||||||
link the user can click on to create their new account.
|
link the user can click on to create their new account.
|
||||||
|
|
Loading…
Reference in a new issue