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

add documentation for setting custom headers

Browse source
This commit is contained in:
Stefan Schwarz 2018-11-29 11:12:57 +01:00 committed by Matthew Helmke
parent 4d9a2b200f
commit f23ede5c1c
1 changed files with 16 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
securing_apps/topics/oidc/keycloak-gatekeeper.adoc
View file

@ -121,6 +121,9 @@ resources:
white-listed: true white-listed: true
- uri: /img/* - uri: /img/*
white-listed: true white-listed: true
headers:
myheader1: value_1
myheader2: value_2
---- ----
Anything defined in a configuration file can also be configured using command line options, such as in this example. Anything defined in a configuration file can also be configured using command line options, such as in this example.
@ -141,7 +144,9 @@ bin/{generic_adapter_name} \
--resources="uri=/backend*|roles=test1" \ --resources="uri=/backend*|roles=test1" \
--resources="uri=/css/*|white-listed=true" \ --resources="uri=/css/*|white-listed=true" \
--resources="uri=/img/*|white-listed=true" \ --resources="uri=/img/*|white-listed=true" \
--resources="uri=/public/*|white-listed=true" --resources="uri=/public/*|white-listed=true" \
--headers="myheader1=value1" \
--headers="myheader2=value2"
---- ----
By default the roles defined on a resource perform a logical `AND` so all roles specified must be present in the claims, this behavior can be altered by the `require-any-role` option, however, so as long as one role is present the permission is granted. By default the roles defined on a resource perform a logical `AND` so all roles specified must be present in the claims, this behavior can be altered by the `require-any-role` option, however, so as long as one role is present the permission is granted.
@ -313,6 +318,16 @@ X-Auth-Given-Name: Beloved
X-Auth-Name: Beloved User X-Auth-Name: Beloved User
---- ----
==== Custom headers
You can inject custom headers using the `--headers="name=value"` option or the configuration file:
[source.yaml]
----
headers:
name: value
----
==== Encryption key ==== Encryption key
In order to remain stateless and not have to rely on a central cache to persist the refresh_tokens, the refresh token is encrypted and added as a cookie using *crypto/aes*. The key must be the same if you are running behind a load balancer. The key length should be either 16 or 32 bytes, depending or whether you want AES-128 or AES-256. In order to remain stateless and not have to rely on a central cache to persist the refresh_tokens, the refresh token is encrypted and added as a cookie using *crypto/aes*. The key must be the same if you are running behind a load balancer. The key length should be either 16 or 32 bytes, depending or whether you want AES-128 or AES-256.