Keycloak 16024 (#36)
* rearranges all client modules into assembly * Adds [role=_abstract] to modules
This commit is contained in:
parent
7f4bd1e915
commit
34af5ab7c2
9 changed files with 22 additions and 23 deletions
|
@ -1,4 +1,3 @@
|
||||||
|
|
||||||
include::topics/overview.adoc[]
|
include::topics/overview.adoc[]
|
||||||
include::topics/overview/features.adoc[]
|
include::topics/overview/features.adoc[]
|
||||||
include::topics/overview/how.adoc[]
|
include::topics/overview/how.adoc[]
|
||||||
|
|
|
@ -2,14 +2,18 @@
|
||||||
|
|
||||||
== Managing Clients
|
== Managing Clients
|
||||||
|
|
||||||
|
role="_abstract"]
|
||||||
Clients are entities that can request authentication of a user. Clients come in two forms.
|
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
|
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
|
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.
|
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.
|
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[]
|
||||||
|
|
|
@ -1,12 +1,9 @@
|
||||||
|
|
||||||
=== Client Links
|
=== 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 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.
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
As an example, given the realm `master` and the client-id `account`:
|
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
|
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
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -3,6 +3,11 @@
|
||||||
[[_client_scopes]]
|
[[_client_scopes]]
|
||||||
=== 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[]
|
include::proc-creating-client-scopes.adoc[]
|
||||||
|
|
||||||
==== Protocol
|
==== Protocol
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
[[_audience]]
|
[[_audience]]
|
||||||
|
|
||||||
==== Audience Support
|
==== 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.
|
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}.
|
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}.
|
||||||
|
|
|
@ -1,10 +1,6 @@
|
||||||
[id="proc_creating_client_scopes_{context}"]
|
[id="proc_creating_client_scopes_{context}"]
|
||||||
|
|
||||||
[role="_abstract"]
|
[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:
|
To create a client scope, follow these steps:
|
||||||
|
|
||||||
. Click `Client Scopes` in the left toolbar.
|
. Click `Client Scopes` in the left toolbar.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
|
|
||||||
==== IDP Initiated Login
|
==== 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.
|
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`.
|
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.
|
This is a simple string with no whitespace in it.
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
[id="proc-creating-saml-client_{context}"]
|
[id="proc-creating-saml-client_{context}"]
|
||||||
|
|
||||||
=== SAML Clients
|
=== SAML Clients
|
||||||
|
[role="_abstract"]
|
||||||
{project_name} supports <<_saml,SAML 2.0>> for registered applications.
|
{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.
|
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.
|
||||||
|
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
[id="proc-using-an-entity-descriptors_{context}"]
|
[id="proc-using-an-entity-descriptors_{context}"]
|
||||||
|
|
||||||
==== Using an entity descriptor to create a client
|
==== 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.
|
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.
|
The Add Client page includes an `Import` option.
|
||||||
|
|
Loading…
Reference in a new issue