88 lines
No EOL
5 KiB
Text
88 lines
No EOL
5 KiB
Text
= Client Scopes and support for OAuth 2 scope parameter
|
|
|
|
We added support for Client Scopes, which replaces Client Templates. Client Scopes are a more flexible approach and also provides
|
|
better support for the OAuth `scope` parameter.
|
|
|
|
There are changes related to Client Scopes to the consent screen. The list on the consent screen is now linked to client scopes
|
|
instead of protocol mappers and roles.
|
|
|
|
See the documentation and migration guide for more details.
|
|
|
|
= OAuth 2 Certificate Bound Access Tokens
|
|
|
|
We now have a partial implementation of the specification
|
|
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08[OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens] .
|
|
More accurately we have support for the Certificate Bound Access Tokens. If your confidential client is able to use 2-way SSL,
|
|
{project_name} will be able to add the hash of the client certificate into the tokens issued for the client. At this moment,
|
|
it's just the {project_name} itself, which verifies the token hashes (for example during `refresh token` requests).
|
|
We plan to add support to adapters as well. We also plan to add support for Mutual TLS Client Authentication.
|
|
|
|
Thanks to https://github.com/tnorimat[tnorimat] for the contribution.
|
|
|
|
= Authorization Services
|
|
|
|
== UMA 2.0 Support
|
|
|
|
UMA 2.0 is now supported for Authorization Services. Check the documentation for more details
|
|
if you are coming from previous versions of {project_name}.
|
|
|
|
=== User-Managed Access through the {project_name} Account Service
|
|
|
|
Now end-users are able to manage their resources and the permissions associated with them through the {project_name} Account Service.
|
|
From there, resource owners can now check their resources, share resources with another users as well approve requests from other users.
|
|
|
|
=== Asynchronous Authorization Flow
|
|
|
|
When using UMA, client applications can now choose whether or not an authorization request should start an authorization flow
|
|
to ask for the resource owner approval. This functionality allows applications to ask for resource owner
|
|
approval when trying to access one of his resources on behalf of another user.
|
|
|
|
=== User-Managed Permission API
|
|
|
|
Resource servers are now capable of associating additional policies to resources owned by a particular user. The new API provides
|
|
operations to manage these permissions using different policy types such as role, group, user, client or a condition using JavaScript.
|
|
|
|
== Pushed Claims
|
|
|
|
Clients applications are now able to send arbitrary claims to {project_name} along with an authorization request in order to
|
|
evaluate permissions based on these claims. This is a very handy addition when access
|
|
should be granted (or denied) in the scope of a specific transaction or based on information about the runtime.
|
|
|
|
== Resource Attributes
|
|
|
|
It is now possible to associated attributes with resources protected by {project_name} and use these same attributes to evaluate permissions
|
|
from your policies.
|
|
|
|
== Policy enforcer now accepts regular access tokens
|
|
|
|
In some situations, you may want to just send regular access tokens to a resource server but still be able to enforce policies on these resources.
|
|
|
|
One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in
|
|
order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular
|
|
access tokens as a bearer token and permissions will still be enforced.
|
|
|
|
== Policy enforcer can now load resources from the server on-demand
|
|
|
|
Until now, when deploying an application configured with a `policy-enforcer`, the policy enforcer would either load all protected paths
|
|
from the server or just map these paths from the adapter configuration. Users can now decide to load paths on-demand from the server and avoid
|
|
map these resources in the adapter configuration. Depending on how many protected resources you have this functionality can also improve the time to
|
|
deploy an application.
|
|
|
|
== Policy enforcer now supports configuring the resource cache
|
|
|
|
In order to avoid unnecessary hits to the server, the policy enforcer caches the mapping between protected resources and their corresponding paths
|
|
in your application. Users can now configure the behaviour of the cache or even completely disable it.
|
|
|
|
== Claim Information Points
|
|
|
|
The `policy-enforcer` definition on the adapters (`keycloak.json`) was also updated to support the concept of pushed claims. There
|
|
you have the concept of a `claim-information-point` which can be set to push claims from different sources such as the HTTP request or even
|
|
from an external HTTP service.
|
|
|
|
== Improvements to the Evaluation API
|
|
|
|
The Evaluation API used to implement policies in {project_name}, especially JavaScript and Drools policies, provides now methods to:
|
|
|
|
* Access information from the current realm such as check for user roles, groups and attributes
|
|
* Push back arbitrary claims to the resource server in order to provide additional information on how a specific permissions should
|
|
be enforced |