Keycloak 16024 (#36)

* rearranges all client modules into assembly

* Adds [role=_abstract] to modules
This commit is contained in:
Brian Dooley 2020-10-30 15:43:38 +00:00 committed by Marek Posolda
parent 7f4bd1e915
commit 34af5ab7c2
9 changed files with 22 additions and 23 deletions

View file

@ -1,4 +1,3 @@
include::topics/overview.adoc[]
include::topics/overview/features.adoc[]
include::topics/overview/how.adoc[]

View file

@ -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[]

View file

@ -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

View file

@ -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

View file

@ -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}.

View file

@ -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.

View file

@ -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.

View file

@ -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.

View file

@ -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.