Fix spelling for HTTP requests
This commit is contained in:
parent
59c8d7880e
commit
1fbaba133f
4 changed files with 9 additions and 9 deletions
|
@ -15,7 +15,7 @@ When requesting an RPT, you need to provide two things:
|
|||
* A <<_service_protection_permission_api_papi, permission ticket>> representing the resources you want to access
|
||||
* The <<_service_authorization_aat, Authorization API token (AAT)>> (as a bearer token) representing a user's identity and his consent to access authorization data on his behalf.
|
||||
|
||||
The permission ticket is added to a HTTP request as a parameter whether the AAT is included in a ```Authorization``` header in order to authenticate de request
|
||||
The permission ticket is added to an HTTP request as a parameter whether the AAT is included in a ```Authorization``` header in order to authenticate the request
|
||||
using the AAT as a bearer token.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -27,7 +27,7 @@ provides an easy way to obtain entitlements from the server, it might not be app
|
|||
with an user. In this case, the **POST** method is recommended.
|
||||
|
||||
Regardless of the HTTP method you decide to use, the Entitlement API endpoint expects an access token in the request representing a user's identity
|
||||
and his consent to access authorization data on his behalf. The access token must be sent as a bearer token using a HTTP ```Authorization``` header.
|
||||
and his consent to access authorization data on his behalf. The access token must be sent as a bearer token using an HTTP ```Authorization``` header.
|
||||
|
||||
After successfully invoking the Entitlement API endpoint, you will get a <<_service_rpt_overview, RPT>> with all permissions
|
||||
granted by the server.
|
||||
|
|
|
@ -72,21 +72,21 @@ The `default` client registration provider can be used to create, retrieve, upda
|
|||
It uses {project_name} Client Representation format which provides support for configuring clients exactly as they can be configured through the admin
|
||||
console, including for example configuring protocol mappers.
|
||||
|
||||
To create a client create a Client Representation (JSON) then do a HTTP POST to `/realms/<realm>/clients-registrations/default`.
|
||||
To create a client create a Client Representation (JSON) then perform an HTTP POST request to `/realms/<realm>/clients-registrations/default`.
|
||||
|
||||
It will return a Client Representation that also includes the registration access token.
|
||||
You should save the registration access token somewhere if you want to retrieve the config, update or delete the client later.
|
||||
|
||||
To retrieve the Client Representation then do a HTTP GET to `/realms/<realm>/clients-registrations/default/<client id>`.
|
||||
To retrieve the Client Representation perform an HTTP GET request to `/realms/<realm>/clients-registrations/default/<client id>`.
|
||||
|
||||
It will also return a new registration access token.
|
||||
|
||||
To update the Client Representation then do a HTTP PUT to with the updated Client Representation to:
|
||||
To update the Client Representation perform an HTTP PUT request with the updated Client Representation to:
|
||||
`/realms/<realm>/clients-registrations/default/<client id>`.
|
||||
|
||||
It will also return a new registration access token.
|
||||
|
||||
To delete the Client Representation then do a HTTP DELETE to:
|
||||
To delete the Client Representation perform an HTTP DELETE request to:
|
||||
`/realms/<realm>/clients-registrations/default/<client id>`
|
||||
|
||||
=== {project_name} Adapter Configuration
|
||||
|
@ -100,7 +100,7 @@ To do this include the following header in the request:
|
|||
Authorization: basic BASE64(client-id + ':' + client-secret)
|
||||
----
|
||||
|
||||
To retrieve the Adapter Configuration then do a HTTP GET to `/realms/<realm>/clients-registrations/install/<client id>`.
|
||||
To retrieve the Adapter Configuration then perfrom an HTTP GET request to `/realms/<realm>/clients-registrations/install/<client id>`.
|
||||
|
||||
No authentication is required for public clients.
|
||||
This means that for the JavaScript adapter you can load the client configuration directly from {project_name} using the above URL.
|
||||
|
@ -120,7 +120,7 @@ It doesn't support retrieving, updating or deleting clients.
|
|||
For those operations the {project_name} representation endpoints should be used.
|
||||
When creating a client a {project_name} Client Representation is returned with details about the created client, including a registration access token.
|
||||
|
||||
To create a client do a HTTP POST with the SAML Entity Descriptor to `/realms/<realm>/clients-registrations/saml2-entity-descriptor`.
|
||||
To create a client perform an HTTP POST request with the SAML Entity Descriptor to `/realms/<realm>/clients-registrations/saml2-entity-descriptor`.
|
||||
|
||||
=== Example using CURL
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ When an action token is passed to a {project_name} endpoint
|
|||
`_KEYCLOAK_ROOT_/auth/realms/master/login-actions/action-token` via `key` parameter, it is validated and a proper action
|
||||
token handler is executed. The processing always takes place in a context of an authentication session, either a fresh
|
||||
one or the action token service joins an existing authentication session (details are described below). The action token
|
||||
handler can perform actions prescribed by the token (often it alters the authentication session) and results into a HTTP
|
||||
handler can perform actions prescribed by the token (often it alters the authentication session) and results into an HTTP
|
||||
response (e.g. it can continue in authentication or display an information/error page). These steps are detailed below.
|
||||
|
||||
1. *Basic action token validation.* Signature and time validity is checked, and action token handler is determined based
|
||||
|
|
Loading…
Reference in a new issue