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

fixes

Browse source
This commit is contained in:
Bill Burke 2016-05-31 21:22:53 -04:00
parent a956c701dd
commit 95c5959142
3 changed files with 12 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
SUMMARY.adoc
View file

@ -102,6 +102,5 @@
.. link:topics/threat/scope.adoc[Limiting Scope]
.. link:topics/threat/sql.adoc[SQL Injection Attacks]
. link:topics/MigrationFromOlderVersions.adoc[Migration from older versions]
. link:topics/cors.adoc[CORS]

18
topics/clients/client-oidc.adoc
View file

@ -113,13 +113,19 @@ See link:{{book.adapterguide.link}}[{{book.adapterguide.name}}] for more informa
*Web Origins*
This setting is related to browser Javascript making cross-domain XHR HTTP requests to your application. It is central
place to maintain a list
of domains that are allowed to make link:http://www.w3.org/TR/cors/[CORS] requests to your application. This information is stuffed in the
access token. {{book.project.name}} specific client adapters can make use of this token information to decide whether to allow
a CORS request to process. See link:{{book.adapterguide.link}}[{{book.adapterguide.name}}] for more information.
This option centers around link:http://www.w3.org/TR/cors/[CORS] which stands for Cross-Origin Resource Sharing.
If executing browser Javascript tries to make an AJAX HTTP request to a server whose domain is different than the one the
Javascript code came from, then the request uses the CORS.
The server must handle CORS requests in a special way, otherwise the browser will not display or allow the request to be processed.
This protocol exists to protect against XSS, CSRF and other Javascript-based attacks.
Enter in a base URL and click the + sign to add. Click the - sign next to URLs you want to remove.
{{book.project.name}} has support for validated CORS requests. The way it works is that the domains listed in the
`Web Origins` setting for the client are embedded within the access token sent to the client application. The client
application can then use this information to decide whether or not to allow a CORS request to be invoked on it. This is
an extension to the OIDC protocol so only {{book.project.name}} client adapters support this feature.
See link:{{book.adapterguide.link}}[{{book.adapterguide.name}}] for more information.
To fill in the `Web Origins` data, enter in a base URL and click the + sign to add. Click the - sign next to URLs you want to remove.
Remember that you still have to click the `Save` button!

47
topics/cors.adoc
View file

@ -1,47 +0,0 @@
= CORS
CORS stands for Cross-Origin Resource Sharing.
If executing browser Javascript tries to make an AJAX HTTP request to a server's whose domain is different than the one the Javascript code came from, then the request uses the http://www.w3.org/TR/cors/[CORS protocol].
The server must handle CORS requests in a special way, otherwise the browser will not display or allow the request to be processed.
This protocol exists to protect against XSS and other Javascript-based attacks.
Keycloak has support for validated CORS requests.
Keycloak's CORS support is configured per client.
You specify the allowed origins in the client's configuration page in the admin console.
You can add as many you want.
The value must be what the browser would send as a value in the `Origin` header.
For example `http://example.com` is what you must specify to allow CORS requests from `example.com`.
When an access token is created for the client, these allowed origins are embedded within the token.
On authenticated CORS requests, your application's Keycloak adapter will handle the CORS protocol and validate the `Origin` header against the allowed origins embedded in the token.
If there is no match, then the request is denied.
To enable CORS processing in your application's server, you must set the `enable-cors` setting to `true` in your <<_adapter_config,adapter's configuration file>>.
When this setting is enabled, the Keycloak adapter will handle all CORS preflight requests.
It will validate authenticated requests (protected resource requests), but will let unauthenticated requests (unprotected resource requests) pass through.
== Handling CORS Yourself
This section is for Java developers securing servlet-based applications using our servlet adapter.
If you don't like our CORS support you can handle it yourself in a filter or something.
One problem you will encounter is that our adapter will may trigger for any CORS preflight OPTIONS requests to blindly secured URLs.
This will result in 302 redirection or 401 responses for the preflight OPTIONS request.
To workaround this problem, you must modify your web.xml security constraints to let OPTIONS requests through
[source]
----
<security-constraint>
<web-resource-collection>
<web-resource-name>wholesale</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
...
</security-constraint>
----
The above security constraint will secure all URLs, but only on GET, POST, PUT, and DELETE calls.
OPTIONS requests will be let through.