Skip to content

Open issues and limitations

Luca Leonardo Scorcia edited this page Aug 3, 2020 · 2 revisions

There are a few major issues with Keycloak that unfortunately prevent SPID login to be a trusted authentication mechanism. Please read these problems and try to understand whether they are indeed problematic in your scenario (they are for mine).

1) Users logging in with SPID can edit their data

Unfortunately that's just the way Keycloak works. Once a user is logged in, he can access its /account portal and change his own name, password or email. You can block username changes, but that's it. Even blocking the account portal, a malicious user can invoke the Keycloak REST endpoints directly to edit its own attributes.

Setting the Sync Mode to Force somewhat mitigates this problem, i.e. the user data gets reset to the SPID values at the next SPID login, but this doesn't ensure the data has not been modified.

2) Email address changes are not verified

Even worse than issue 1), users can change their email address and there is no verification mechanism for the actual ownership of the new email address. There is a very old request for the feature on the Keycloak tracker (https://issues.redhat.com/browse/KEYCLOAK-6455), so maybe someday this will be implemented.

3) An IdP user is a local user and can set his own password for local login

Keycloak imports the remote user in his local user storage, therefore an IdP user can set his own password, or request a password reset. Since the username can easily be retrieved from the authentication token or the /account portal, this is not just a theoretical problem. Once a user has set a password for his account there is nothing stopping him from logging in locally, still returning to the application the SPID attributes even if not in a SPID session.

This can be mitigated by adding a Protocol Mapper in the Clients configuration. A User Session Note mapper with the value identity_provider will be set to the Alias of the remote IdP, and will be empty if the user logged in locally. This means that applications can at least check if the user comes from a SPID session.

Other issues

For any other issue you may be facing, feel free to report it as a GitHub issue. We'll try to figure it out together.