diff --git a/server_admin/topics.adoc b/server_admin/topics.adoc index 17d86fca97..5cba021393 100644 --- a/server_admin/topics.adoc +++ b/server_admin/topics.adoc @@ -1,4 +1,3 @@ - include::topics/overview.adoc[] include::topics/overview/features.adoc[] include::topics/overview/how.adoc[] diff --git a/server_admin/topics/clients.adoc b/server_admin/topics/clients.adoc index d00900bd59..9c4aba2afd 100644 --- a/server_admin/topics/clients.adoc +++ b/server_admin/topics/clients.adoc @@ -2,14 +2,18 @@ == Managing Clients +role="_abstract"] Clients are entities that can request authentication of a user. Clients come in two forms. The first type of client is an application that wants to participate in single-sign-on. These clients just want {project_name} to provide security for them. The other type of client is one that is requesting an access token so that it can invoke other services on behalf of the authenticated user. This section discusses various aspects around configuring clients and various ways to do it. - - - - - +include::clients/client-oidc.adoc[] +include::clients/saml/proc-creating-saml-client.adoc[] +include::clients/saml/idp-initiated-login.adoc[] +include::clients/saml/proc-using-an-entity-descriptor.adoc[] +include::clients/client-link.adoc[] +include::clients/con-protocol-mappers.adoc[] +include::clients/proc-generating-client-adapter-config.adoc[] +include::clients/con-client-scopes.adoc[] diff --git a/server_admin/topics/clients/client-link.adoc b/server_admin/topics/clients/client-link.adoc index 154fbafa11..8ffe7d01b2 100644 --- a/server_admin/topics/clients/client-link.adoc +++ b/server_admin/topics/clients/client-link.adoc @@ -1,12 +1,9 @@ === Client Links +[role="_abstract"] +To link from one client to another, {project_name} provides a redirect endpoint: `/realms/realm_name/clients/\{client-id}/redirect`. -For scenarios where one wants to link from one client to another, {project_name} provides a special redirect endpoint: `/realms/realm_name/clients/\{client-id}/redirect`. - -If a client accesses this endpoint via an `HTTP GET` request, {project_name} returns the configured base URL for the provided Client and Realm in the form of an `HTTP 307` (Temporary Redirect) via the response's `Location` header. - -Thus, a client only needs to know the Realm name and the Client ID in order to link to them. -This indirection helps avoid hard-coding client base URLs. +If a client accesses this endpoint using a `HTTP GET` request, {project_name} returns the configured base URL for the provided Client and Realm in the form of an `HTTP 307` (Temporary Redirect) in the response's `Location` header. As a result of this, a client needs only to know the Realm name and the Client ID to link to them. This indirection avoids hard-coding client base URLs. As an example, given the realm `master` and the client-id `account`: @@ -14,6 +11,4 @@ As an example, given the realm `master` and the client-id `account`: ---- http://host:port/auth/realms/master/clients/account/redirect ---- -Would temporarily redirect to: http://host:port/auth/realms/master/account - - +This URL temporarily redirects to: http://host:port/auth/realms/master/account diff --git a/server_admin/topics/clients/con-client-scopes.adoc b/server_admin/topics/clients/con-client-scopes.adoc index 8d7882cfcc..2a9074f161 100644 --- a/server_admin/topics/clients/con-client-scopes.adoc +++ b/server_admin/topics/clients/con-client-scopes.adoc @@ -3,6 +3,11 @@ [[_client_scopes]] === Client Scopes +[role="_abstract"] +{project_name} allows you to define a shared client configuration in an entity called a _client scope_. This entity allows you to configure <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>> for multiple clients. + +Client scopes also support the OAuth 2 `scope` parameter. This parameter allows client applications to request more or fewer claims or roles in the access token, depending on the requirement of the application. + include::proc-creating-client-scopes.adoc[] ==== Protocol diff --git a/server_admin/topics/clients/oidc/con-audience.adoc b/server_admin/topics/clients/oidc/con-audience.adoc index 15da27c234..3c01805556 100644 --- a/server_admin/topics/clients/oidc/con-audience.adoc +++ b/server_admin/topics/clients/oidc/con-audience.adoc @@ -3,7 +3,7 @@ [[_audience]] ==== Audience Support - +[role="_abstract"] Typically, the environment where {project_name} is deployed consists of a set of _confidential_ or _public_ client applications that use {project_name} for authentication. There are also _services_ (_Resource Servers_ in the https://tools.ietf.org/html/draft-ietf-oauth-mtls-08#section-4.2[OAuth 2 specification]) that serve requests from client applications and provide resources to these applications. These services require an _Access token_ (Bearer token) to be sent to them to authenticate a request. This token is obtained by the frontend application upon login to {project_name}. diff --git a/server_admin/topics/clients/proc-creating-client-scopes.adoc b/server_admin/topics/clients/proc-creating-client-scopes.adoc index 67fd406de1..a5754b5a58 100644 --- a/server_admin/topics/clients/proc-creating-client-scopes.adoc +++ b/server_admin/topics/clients/proc-creating-client-scopes.adoc @@ -1,10 +1,6 @@ [id="proc_creating_client_scopes_{context}"] [role="_abstract"] -{project_name} allows you to define a shared client configuration in an entity called a _client scope_. This entity allows you to configure <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>> for multiple clients. - -Client scopes also support the OAuth 2 `scope` parameter. This parameter allows client applications to request more or fewer claims or roles in the access token, depending on the requirement of the application. - To create a client scope, follow these steps: . Click `Client Scopes` in the left toolbar. diff --git a/server_admin/topics/clients/saml/idp-initiated-login.adoc b/server_admin/topics/clients/saml/idp-initiated-login.adoc index 0a001127f8..de4ca73574 100644 --- a/server_admin/topics/clients/saml/idp-initiated-login.adoc +++ b/server_admin/topics/clients/saml/idp-initiated-login.adoc @@ -1,6 +1,6 @@ ==== IDP Initiated Login - +[role="_abstract"] IDP Initiated Login is a feature that allows you to set up an endpoint on the {project_name} server that will log you into a specific application/client. In the `Settings` tab for your client, you need to specify the `IDP Initiated SSO URL Name`. This is a simple string with no whitespace in it. diff --git a/server_admin/topics/clients/saml/proc-creating-saml-client.adoc b/server_admin/topics/clients/saml/proc-creating-saml-client.adoc index 4523a8b109..9c8adb3a1b 100644 --- a/server_admin/topics/clients/saml/proc-creating-saml-client.adoc +++ b/server_admin/topics/clients/saml/proc-creating-saml-client.adoc @@ -1,7 +1,7 @@ [id="proc-creating-saml-client_{context}"] === SAML Clients - +[role="_abstract"] {project_name} supports <<_saml,SAML 2.0>> for registered applications. POST and Redirect bindings are supported. You can choose to require client signature validation. You can have the server sign and/or encrypt responses as well. diff --git a/server_admin/topics/clients/saml/proc-using-an-entity-descriptor.adoc b/server_admin/topics/clients/saml/proc-using-an-entity-descriptor.adoc index cdd8eba690..0be47d651c 100644 --- a/server_admin/topics/clients/saml/proc-using-an-entity-descriptor.adoc +++ b/server_admin/topics/clients/saml/proc-using-an-entity-descriptor.adoc @@ -1,7 +1,7 @@ [id="proc-using-an-entity-descriptors_{context}"] ==== Using an entity descriptor to create a client - +[role="_abstract"] Instead of registering a SAML 2.0 client manually, you can import the client using a standard SAML Entity Descriptor XML file. The Add Client page includes an `Import` option.