Chapter 6. Red Hat Single Sign-On Continuous Delivery 7.3.CD02

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

6.2. OAuth 2 Certificate Bound Access Tokens

We now have a partial implementation of the specification 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, Red Hat Single Sign-On 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 Red Hat Single Sign-On 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 tnorimat for the contribution.

6.3. Authorization Services

6.3.1. 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 Red Hat Single Sign-On.

6.3.1.1. User-Managed Access through the Red Hat Single Sign-On Account Service

Now end-users are able to manage their resources and the permissions associated with them through the Red Hat Single Sign-On Account Service. From there, resource owners can now check their resources, share resources with another users as well approve requests from other users.

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

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

6.3.2. Pushed Claims

Clients applications are now able to send arbitrary claims to Red Hat Single Sign-On 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.

6.3.3. Resource Attributes

It is now possible to associated attributes with resources protected by Red Hat Single Sign-On and use these same attributes to evaluate permissions from your policies.

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

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

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

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

6.3.8. Improvements to the Evaluation API

The Evaluation API used to implement policies in Red Hat Single Sign-On, 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

6.4. Authorization Services

6.4.1. UMA 2.0

UMA 2.0 is now supported for Authorization Services, including support for users to manage user access through the account management console. There are also other additions and improvements to authorization services.

6.4.2. Pushed Claims

Clients can now push additional claims and have them used by policies when evaluating permissions.

6.4.3. Resource Attributes

It is now possible to define attributes on resources in order to have them used by policies when evaluating permissions.

6.5. Themes and Theme Resources

It is now possible to hot-deploy themes to Keycloak through a regular provider deployment. We have also added support for theme resources, which allows adding additional templates and resources without creating a theme. This is useful for custom authenticators that require additional pages to be added to the authentication flow.

We have also added support to override the theme for specific clients. If that is not adequate for your needs, then there is also a new Theme Selector SPI that allows you to implement custom logic to select the theme.

6.6. Instagram Identity Provider

We have added support to login with Instagram. Thanks to hguerrero for the contribution.

6.7. Search by User ID in Admin Console

To search for a user by id in the admin console you previously had to edit the URL. It is now possible to search directly in the user search field.

6.8. Adapters

6.8.1. Spring Boot 2

We now have support for Spring Boot 2.

6.8.2. Fuse 7

We now have support for Fuse 7.

6.8.3. JavaScript - Native Promise Support

The JavaScript adapter now supports native promises. It retains support for the old style promises as well. Both can be used interchangeably.

6.8.4. JavaScript - Cordova Options

It is now possible to pass Cordova-specific options to login and other methods in the JavaScript adapter. Thanks to loorent for the contribution.