libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

Merge pull request #211 from muehlburger/master

Browse source 
Fix spelling for HTTP requests
This commit is contained in:
Stian Thorgersen 2017-10-05 13:24:17 +02:00 committed by GitHub
commit 8f1e6ed8e9
5 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
authorization_services/topics/service/authorization/authorization-api-aapi.adoc
View file

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

2
authorization_services/topics/service/entitlement/entitlement-api-aapi.adoc
View file

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

12
securing_apps/topics/client-registration.adoc
View file

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

2
securing_apps/topics/oidc/java/java-adapter-config.adoc
View file

@ -208,7 +208,7 @@ token-store::
See <<_applicationclustering,Application Clustering>> for details
principal-attribute::
OpenID Connection ID Token attribute to populate the UserPrincipal name with.
OpenID Connect ID Token attribute to populate the UserPrincipal name with.
If token attribute is null, defaults to `sub`.
Possible values are `sub`, `preferred_username`, `email`, `name`, `nickname`, `given_name`, `family_name`.

2
server_development/topics/action-token-spi.adoc
View file

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