Open issues and limitations - italia/spid-keycloak-provider GitHub Wiki
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.