Blogs

Blogs

Liferay SSO - UserInfo data mapping

Breaking changes with the latest DXP 7.3 fix packs

I've often been asked whether we can process additional UserInfo data from an OpenId Connect session after successful log in.

I used to share this piece of code where I had my way to access the OpenIdConnect Session object in order to retrieve the Access Token Liferay obtained in order to fetch additional info: https://github.com/fabian-bouche-liferay/oidc-userinfo-mapping/

However, last time I shared that piece of code, the developer got back to me and told be it did not work, getting this exception:

2021-12-20 09:26:36.838 ERROR [http-nio-8080-exec-3][MainServlet:574] java.lang.ClassCastException: [B cannot be cast to com.liferay.portal.security.sso.openid.connect.OpenIdConnectSession

Fixing the access to the OpenId Connect session

And indeed, there have been some recent changes in the Liferay OIDC APIs which require to adapt the post login action.

You'll find a new version of the code under this new branch: https://github.com/fabian-bouche-liferay/oidc-userinfo-mapping/tree/new

The first change I've spotted is that you cannot access the OpenId Connect session object directly from the session, you have to go through that new service:

@Reference
private OpenIdConnectSessionProvider _openIdConnectSessionProvider;

And call:

_openIdConnectSessionProvider.getOpenIdConnectSession(httpSession);

The second change I have spotted is that the original method to access the OpenID Connect provider metadata has been deprecated in favour of this one:

openIdConnectProvider = _openIdConnectProviderRegistry.findOpenIdConnectProvider(_portal.getCompanyId(lifecycleEvent.getRequest()), openIdProviderName);

What else you can do with the OpenId Connect session

OpenID Connect is a protocol built on top of OAuth 2.0. As a consequence, when Liferay is doing the OIDC Authorization Code Flow against your OpenID Provider, it is also doing an OAuth 2.0 Authorization Code flow against it.

You can take advantage of that by requesting additional scopes in the OIDC Provider configuration:

That could be useful if at some point you need to make some API calls from your Java controllers which require an Access Token with a specific scope.