91 lines
6.2 KiB
Text
91 lines
6.2 KiB
Text
== RH-SSO 7.2
|
|
|
|
The following changes have occurred from RH-SSO 7.1 to RH-SSO 7.2.
|
|
|
|
=== New password hashing algorithms
|
|
|
|
We have added two new password hashing algorithms (pbkdf2-sha256 and pbkdf2-sha512). New realms will use the pbkdf2-sha256
|
|
hashing algorithm with 27500 hashing iterations. Since pbkdf2-sha256 is slightly faster than pbkdf2 the iterations was
|
|
increased to 27500 from 20000.
|
|
|
|
Existing realms are upgraded if the password policy contains the default value for the hashing algorithm (not specified) and
|
|
iteration (20000). If you have changed the hashing iterations, you need to manually change to pbkdf2-sha256 if you'd like
|
|
to use the more secure hashing algorithm.
|
|
|
|
=== ID Token requires scope=openid
|
|
|
|
In RH-SSO 7.0, the ID Token was returned regardless if `scope=openid` query parameter was present or not in authorization
|
|
request. This is incorrect according to the OpenID Connect specification.
|
|
|
|
In RH-SSO 7.1, we added this query parameter to adapters, but left the old behavior to accommodate migration.
|
|
|
|
In RH-SSO 7.2, this behavior has changed and the `scope=openid` query parameter is now required to mark the request as an
|
|
OpenID Connect request. If this query parameter is omitted the ID Token will not be generated.
|
|
|
|
=== Microsoft SQL Server requires extra dependency
|
|
|
|
Microsoft JDBC Driver 6.0 requires additional dependency added to the JDBC driver module. If you observe an
|
|
`NoClassDefFoundError` error when using Microsoft SQL Server please add the following dependency to your JDBC driver
|
|
`module.xml` file:
|
|
|
|
[source,xml]
|
|
----
|
|
<module name="javax.xml.bind.api"/>
|
|
----
|
|
|
|
=== Added session_state parameter to OpenID Connect Authentication Response
|
|
|
|
The OpenID Connect Session Management specification requires that the parameter `session_state` is present in the OpenID Connect Authentication Response.
|
|
|
|
In RH-SSO 7.1, we did not have this parameter, but now {project_name} adds this parameter by default, as required by the specification.
|
|
|
|
However, some OpenID Connect / OAuth2 adapters, and especially older {project_name} adapters (such as RH-SSO 7.1 and older), may have issues with this new parameter.
|
|
|
|
For example, the parameter will be always present in the browser URL after successful authentication to the client application.
|
|
If you use RH-SSO 7.1 or a legacy OAuth2 / OpenID Connect adapter, it may be useful to disable adding the `session_state` parameter to the authentication response.
|
|
This can be done for the particular client in the {project_name} admin console, in client details in the section with `OpenID Connect Compatibility Modes`,
|
|
described in <<_compatibility_with_older_adapters>>. There is the `Exclude Session State From Authentication Response` switch,
|
|
which can be turned on to prevent adding the `session_state` parameter to the Authentication Response.
|
|
|
|
=== Microsoft Identity Provider updated to use the Microsoft Graph API
|
|
|
|
The Microsoft Identity Provider implementation in {project_name} up to version 7.2.4 relies on the Live SDK
|
|
endpoints for authorization and obtaining the user profile. From November 2018 onwards, Microsoft is removing support
|
|
for the Live SDK API in favor of the new Microsoft Graph API. The {project_name} identity provider has been updated
|
|
to use the new endpoints so if this integration is in use make sure you upgrade to {project_name} version 7.2.5 or later.
|
|
|
|
Legacy client applications registered under "Live SDK applications" won't work with the Microsoft Graph endpoints
|
|
due to changes in the id format of the applications. 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://account.live.com/developers/applications/create[Microsoft Application Registration] portal to obtain a new application id.
|
|
|
|
=== Google Identity Provider updated to use Google Sign-in authentication system
|
|
|
|
The Google Identity Provider implementation in {project_name} up to version 7.2.5 relies on the Google+ API endpoints
|
|
for authorization and obtaining the user profile. From March 2019 onwards, Google is removing support
|
|
for the Google+ API in favor of the new Google Sign-in authentication system. The {project_name} identity provider has been updated
|
|
to use the new endpoints so if this integration is in use make sure you upgrade to {project_name} version 7.2.6 or later.
|
|
|
|
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.cloud.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 so if this integration is in use make sure you upgrade to {project_name} version 7.2.6 or later.
|
|
|
|
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.
|