We added support for UMA 2.0. This version of the UMA specification introduced some important changes on how permissions are obtained from the server.
Here are the main changes introduced by UMA 2.0 support. See link:{authorizationguide_link}[{authorizationguide_name}] for details.
Authorization API was removed::
Prior to UMA 2.0 (UMA 1.0), client applications were using the Authorization API to obtain permissions from the server in the format of a RPT. The new version
of UMA specification has removed the Authorization API which was also removed from {project_name}. In UMA 2.0, RPTs can now be obtained from the token endpoint by using a specific grant type.
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
Entitlement API was removed::
With the introduction of UMA 2.0, we decided to leverage the token endpoint and UMA grant type to allow obtaining RPTs from {project_name} and
avoid having different APIs. The functionality provided by the Entitlement API was kept the same and is still possible to obtain permissions for a set
of one or more resources and scopes or all permissions from the server in case no resource or scope is provided.
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
Changes to UMA Discovery Endpoint::
UMA Discovery document changed, see link:{authorizationguide_link}#_service_authorization_api[{authorizationguide_name}] for details.
Changes to {project_name} Authorization JavaScript Adapter::
The {project_name} Authorization JavaScript Adapter (keycloak-authz.js) changed in order to comply with the changes introduced by UMA 2.0 while keeping
the same behavior as before. The main change is on how you invoke both `authorization` and `entitlement` methods which now
expect a specific object type representing an authorization request. This new object type provides more flexibility on how
permissions can be obtained from the server by supporting the different parameters supported by the UMA grant type.
See link:{authorizationguide_link}#_enforcer_js_adapter[{authorizationguide_name}] for details.
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.
Changes to {project_name} Authorization Client Java API::
When upgrading to the new version of {project_name} Authorization Client Java API, you'll notice that some representation classes
were moved to a different package in `org.keycloak:keycloak-core`.
=== Client Templates changed to Client Scopes
We added support for Client Scopes, which requires some attention during migration.
Client Templates changed to Client Scopes::
Client Templates were changed to Client Scopes. If you had any Client Templates, their protocol mappers and role scope mappings
will be preserved.
Spaces replaced in the names::
Client templates with the space character in the name were renamed by replacing spaces with an underscore, because spaces are
not allowed in the name of client scopes. For example, a client template `my template` will be changed to client scope `my_template`.
Linking Client Scopes to Clients::
For clients which had the client template, the corresponding client scope
is now added as `Default Client Scope` to the client. So protocol mappers and role scope mappings will be preserved on the client.
Realm Default Client Scopes not linked with existing clients::
During the migration, the list of built-in client scopes is added to each realm as well as list of `Realm Default Client Scopes`. However,
existing clients are NOT upgraded and new client scopes are NOT automatically added to them. Also all the protocol mappers and role
scope mappings are kept on existing clients. In the new version, when you create a new client, it automatically has Realm Default Client Scopes
attached to it and it does not have any protocol mappers attached to it. We did not change existing clients during migration as it
would be impossible to properly detect customizations, which you will have for protocol mappers of the clients, for example. If you want to
update existing clients (remove protocol mappers from them and link them with client scopes), you will need to do it manually.
Consents need to be confirmed again::
The client scopes change required the refactoring of consents. Consents now point to client scopes, not to roles or protocol mappers.
Because of this change, the previously confirmed persistent consents by users are not valid anymore and users need to confirm
the consent page again after the migration.
Some configuration switches removed::
The switch `Scope Param Required` was removed from Role Detail. The switches `Consent Required` and `Consent Text` were removed
from the Protocol Mapper details. Those switches were replaced by the Client Scope feature.
If you run into an error saying that the application identifier was not found in the directory, you will have to register the client application again in the
https://console.developers.google.com/apis/credentials[Google API Console] portal to obtain a new application id and secret.
It is possible that you will need to adjust custom mappers for non-standard claims that were provided by Google+ user
information endpoint and are provided under different name by Google Sign-in API. Please consult Google documentation
for the most up-to-date information on available claims.
=== LinkedIn Social Broker Updated to Version 2 of LinkedIn APIs
Accordingly with LinkedIn, all developers need to migrate to version 2.0 of their APIs and OAuth 2.0. As such, we have updated
our LinkedIn Social Broker.
Existing deployments using this broker may start experiencing errors when fetching user's profile using version 2 of
LinkedIn APIs. This error may be related with the lack of permissions granted to the client application used to configure the broker
which may not be authorized to access the Profile API or request specific OAuth2 scopes during the authentication process.
Even for newly created LinkedIn client applications, you need to make sure that the client is able to request the `r_liteprofile` and
`r_emailaddress` OAuth2 scopes, at least, as well that the client application can fetch current member's profile from the `https://api.linkedin.com/v2/me` endpoint.
Due to these privacy restrictions imposed by LinkedIn in regards to access to member's information and the limited set of claims returned by the
current member's Profile API, the LinkedIn Social Broker
is now using the member's email address as the default username. That means that the `r_emailaddress` is always set when
sending authorization requests during the authentication.
