https://issues.redhat.com/browse/KEYCLOAK-16069 updating create a realm topic and create an oidc client to work in RHOAM
This commit is contained in:
Andy Munro
Marek Posolda
parent
34af5ab7c2
commit
f84b7fd0ed
9 changed files with 93 additions and 83 deletions
|
|
@ -19,7 +19,7 @@ over any question mark `?` icon. This will pop up tooltip text to describe the
|
|||
The image above shows the tooltip in action.
|
||||
|
||||
include::realms/master.adoc[leveloffset=2]
|
||||
include::realms/create.adoc[leveloffset=2]
|
||||
include::realms/proc-creating-a-realm.adoc[leveloffset=2]
|
||||
include::realms/ssl.adoc[leveloffset=2][]
|
||||
include::realms/cache.adoc[leveloffset=2][]
|
||||
include::realms/email.adoc[leveloffset=2]
|
||||
|
|
|
|||
|
|
@ -2,8 +2,7 @@
|
|||
[[_oidc_clients]]
|
||||
=== OIDC Clients
|
||||
[role="_abstract"]
|
||||
<<_oidc,OpenID Connect>> is the preferred protocol to secure applications. It was designed from the ground up to be web friendly
|
||||
and work best with HTML5/JavaScript applications.
|
||||
xref:con-oidc_{context}[OpenID Connect] is the recommended protocol to secure applications. It was designed from the ground up to be web friendly and it works best with HTML5/JavaScript applications.
|
||||
|
||||
include::proc-creating-oidc-client.adoc[]
|
||||
include::con-basic-settings.adoc[]
|
||||
|
|
|
|||
52
server_admin/topics/clients/oidc/con-basic-settings.adoc
Normal file
52
server_admin/topics/clients/oidc/con-basic-settings.adoc
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
[id="con-basic-settings_{context}"]
|
||||
==== Basic Settings
|
||||
[role="_abstract"]
|
||||
|
||||
When you create an OIDC client, you see the following fields on the `Settings` tab.
|
||||
|
||||
`Client ID`:: The alpha-numeric ID string that is used in OIDC requests and in the {project_name} database to identify the client.
|
||||
|
||||
`Name`:: The name for the client in {project_name} UI screen. To localize
|
||||
the name, set up a replacement string value. For example, a string value such as $\{myapp}. See the link:{developerguide_link}[{developerguide_name}] for more information.
|
||||
|
||||
`Description`:: The description of the client. This setting can also be localized.
|
||||
|
||||
`Enabled`:: When turned off, the client cannot request authentication.
|
||||
|
||||
`Consent Required`:: When turned on, users see a consent page that they can use to grant access to that application. It will also display metadata so the user knows the exact information that the client can access.
|
||||
|
||||
[[_access-type]]`Access Type`:: The type of OIDC client.
|
||||
|
||||
_Confidential_::
|
||||
For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications.
|
||||
|
||||
_Public_::
|
||||
For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs.
|
||||
|
||||
_Bearer-only_::
|
||||
The application allows only bearer token requests. When turned on, this application cannot participate in browser logins.
|
||||
|
||||
`Standard Flow Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-authorization[Authorization Code Flow].
|
||||
|
||||
`Implicit Flow Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-implicit[Implicit Flow].
|
||||
|
||||
`Direct Access Grants Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-direct[Direct Access Grants].
|
||||
|
||||
`Root URL`:: This value adds a prefix to any configured URLS that {project_name} uses.
|
||||
|
||||
`Valid Redirect URIs`:: Required field. Enter a URL pattern and click *+* to add and *-* to remove existing URLs and click *Save*. You can use wildcards at the end of the URL pattern. For example $$http://host.com/*$$
|
||||
+
|
||||
Exclusive redirect URL patterns are typically more secure. See xref:unspecific-redirect-uris_{context}[Unspecific Redirect URIs] for more information.
|
||||
|
||||
`Base URL`:: This URL is used when {project_name} needs to link to the client.
|
||||
|
||||
`Admin URL`:: Callback endpoint for a client. The server uses this URL to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For {project_name} servlet adapters, this URL can be the root URL of the servlet application.
|
||||
For more information, see link:{adapterguide_link}[{adapterguide_name}].
|
||||
|
||||
`Web Origins`:: Enter a URL pattern and click *+* to add and *-* to remove existing URLs. Click *Save*.
|
||||
+
|
||||
This option handles link:https://fetch.spec.whatwg.org/[Cross-Origin Resource Sharing (CORS)].
|
||||
If browser JavaScript attempts an AJAX HTTP request to a server whose domain is different from the one that the
|
||||
JavaScript code came from, the request must use CORS. The server must handle CORS requests, otherwise the browser will not display or allow the request to be processed. This protocol protects against XSS, CSRF, and other JavaScript-based attacks.
|
||||
+
|
||||
Domain URLs listed here are embedded within the access token sent to the client application. The client application uses this information to decide whether to allow a CORS request to be invoked on it. Only {project_name} client adapters support this feature. See link:{adapterguide_link}[{adapterguide_name}] for more information.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
[id="proc-creating-oidc-client_{context}"]
|
||||
==== Creating an Open ID Connect Client
|
||||
==== Creating an OpenID Connect Client
|
||||
[role="_abstract"]
|
||||
To use xref:_oidc[OpenID Connect], an existing application must be secured as an Open ID connect client.
|
||||
To protect an application that uses the OpenID connect protocol, you create a client.
|
||||
|
||||
.Procedure
|
||||
. Click `Clients` in the left navigation pane.
|
||||
|
|
@ -22,52 +22,8 @@ tab.
|
|||
+
|
||||
.Client Settings
|
||||
image:{project_images}/client-settings-oidc.png[Client Settings]
|
||||
+
|
||||
The following list describes each setting:
|
||||
+
|
||||
`Client ID`:: The alpha-numeric ID string that is used in OIDC requests and in the {project_name} database to identify the client.
|
||||
|
||||
`Name`:: The name for the client in {project_name} UI screen. To localize
|
||||
the name, set up a replacement string value. For example, a string value such as $\{myapp}. See the link:{developerguide_link}[{developerguide_name}] for more information.
|
||||
|
||||
`Description`:: The description of the client. This setting can also be localized.
|
||||
|
||||
`Enabled`:: When turned off, the client cannot request authentication.
|
||||
|
||||
`Consent Required`:: When turned on, users see a consent page that they can use to grant access to that application. It will also display metadata so the user knows the exact information that the client can access.
|
||||
|
||||
[[_access-type]]`Access Type`:: The type of OIDC client.
|
||||
|
||||
_Confidential_::
|
||||
For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications.
|
||||
|
||||
_Public_::
|
||||
For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs.
|
||||
|
||||
_Bearer-only_::
|
||||
The application allows only bearer token requests. When turned on, this application cannot participate in browser logins.
|
||||
|
||||
`Standard Flow Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-authorization[Authorization Code Flow].
|
||||
|
||||
`Implicit Flow Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-implicit[Implicit Flow].
|
||||
|
||||
`Direct Access Grants Enabled`:: When enabled, clients can use the OIDC xref:_oidc-auth-flows-direct[Direct Access Grants].
|
||||
|
||||
`Root URL`:: This value adds a prefix to any configured URLS that {project_name} uses.
|
||||
|
||||
`Valid Redirect URIs`:: Required field. Enter a URL pattern and click *+* to add and *-* to remove existing URLs and click *Save*. You can use wildcards at the end of the URL pattern. For example $$http://host.com/*$$
|
||||
+
|
||||
Exclusive redirect URL patterns are typically more secure. See xref:unspecific-redirect-uris_{context}[Unspecific Redirect URIs] for more information.
|
||||
|
||||
`Base URL`:: This URL is used when {project_name} needs to link to the client.
|
||||
|
||||
`Admin URL`:: Callback endpoint for a client. The server uses this URL to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For {project_name} servlet adapters, this URL can be the root URL of the servlet application.
|
||||
For more information, see link:{adapterguide_link}[{adapterguide_name}].
|
||||
|
||||
`Web Origins`:: Enter a URL pattern and click *+* to add and *-* to remove existing URLs. Click *Save*.
|
||||
+
|
||||
This option handles link:https://fetch.spec.whatwg.org/[Cross-Origin Resource Sharing (CORS)].
|
||||
If browser JavaScript attempts an AJAX HTTP request to a server whose domain is different from the one that the
|
||||
JavaScript code came from, the request must use CORS. The server must handle CORS requests, otherwise the browser will not display or allow the request to be processed. This protocol protects against XSS, CSRF, and other JavaScript-based attacks.
|
||||
+
|
||||
Domain URLs listed here are embedded within the access token sent to the client application. The client application uses this information to decide whether to allow a CORS request to be invoked on it. Only {project_name} client adapters support this feature. See link:{adapterguide_link}[{adapterguide_name}] for more information.
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* For more information about fields on the `Settings` tab, see xref:con-basic-settings_{context}[Basic Settings].
|
||||
* For more information about the OIDC protocol, see xref:con-oidc_{context}[OpenID Connect].
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[[_identity_broker_oidc]]
|
||||
=== OpenID Connect v1.0 Identity Providers
|
||||
|
||||
{project_name} can broker identity providers based on the OpenID Connect protocol. These IDPs must support the <<_oidc, Authorization Code Flow>>
|
||||
{project_name} can broker identity providers based on the OpenID Connect protocol. These IDPs must support the xref:proc-creating-oidc-client_{context}[Authorization Code Flow]
|
||||
as defined by the specification in order to authenticate the user and authorize access.
|
||||
|
||||
To begin configuring an OIDC provider, go to the `Identity Providers` left menu item
|
||||
|
|
|
|||
|
|
@ -1,28 +0,0 @@
|
|||
|
||||
[id=proc-creating-a-realm_{context}]
|
||||
= Creating a realm
|
||||
|
||||
You create a realm as a management space where you can create clients, which are applications or services, and create users who need those clients.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Point to the top of the left pane
|
||||
|
||||
. Click *Add Realm*.
|
||||
+
|
||||
.Add Realm Menu
|
||||
image:{project_images}/add-realm-menu.png[]
|
||||
|
||||
. Enter a name for the realm.
|
||||
|
||||
. Click *Create*.
|
||||
|
||||
The current realm is now set to the realm you just created. You can switch between managing different realms by doing a mouse over on the top left corner drop down menu.
|
||||
|
||||
ifdef::standalone[]
|
||||
Alternatively you can import a JSON document that defines your new realm. We'll go over this in more detail in the xref:assembly-exporting-importing_{context}[Export and Import] chapter.
|
||||
endif::[]
|
||||
|
||||
|
||||
|
||||
|
||||
30
server_admin/topics/realms/proc-creating-a-realm.adoc
Normal file
30
server_admin/topics/realms/proc-creating-a-realm.adoc
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
|
||||
[id=proc-creating-a-realm_{context}]
|
||||
= Creating a realm
|
||||
|
||||
[role="_abstract"]
|
||||
You create a realm to provide a management space where you can create users and give them permissions to use applications. At first login, you are typically in the _master_ realm, the top-level realm from which you create other realms.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Point to the top of the left pane.
|
||||
|
||||
. Click *Add Realm*.
|
||||
+
|
||||
.Add Realm Menu
|
||||
image:{project_images}/add-realm-menu.png[]
|
||||
|
||||
. Enter a name for the realm.
|
||||
|
||||
. Click *Create*.
|
||||
+
|
||||
.Create Realm
|
||||
image:{project_images}/create-realm.png[]
|
||||
|
||||
The current realm is now set to the realm you just created. You can switch between managing different realms by pointing to the top left corner to click *Select Realm*.
|
||||
|
||||
ifdef::standalone[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
Alternatively you can import a JSON document that defines your new realm. For more detail, see the xref:assembly-exporting-importing_{context}[Export and Import] chapter.
|
||||
endif::[]
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
[[_oidc]]
|
||||
[id="con-oidc_{context}"]
|
||||
|
||||
=== OpenID Connect
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
[id="proc-creating-user_{context}"]
|
||||
= Creating a user
|
||||
|
||||
[role="_abstract"]
|
||||
You create users in the realm where you intend to have applications needed by those users. Avoid creating users in the master realm, which is only intended for creating other realms.
|
||||
|
||||
.Prerequisite
|
||||
|
|
|
|||
Loading…
Reference in a new issue