Repository navigation
Replies: 3 comments 3 replies
|
On an additional note, the |
|
For anyone interested, I think I got to the expected functionality by doing the following:
{
"saml-mappers": [
{
"name": "Javascript - Prefixed Username",
"fileName": "prefixed-username.js",
"description": "Exports the username with a prefix"
}
]
}
"u-" + user.getUsername();All files can then be added inside a jar (zip) file and moved to the $ zip -r saml-mappers.jar META-INF *.js
$ cp saml-mappers.jar ${KEYCLOAK_DIR}/providers/
$ ${KEYCLOAK_DIR}/bin/kc.sh build
$ systemctl restart keycloakAfterwards, when Keycloak loads the mappers, they will appear as mapper categories when using the Note: There are still some issues with this approach - the old mappers are still in the database, but they do not show in the admin interface so they cannot be easily deleted; because of this, the new mappers will need to have a different name. I am not sure how to delete the old mappers cleanly, or if they can cause some issues with duplicated exported data in some instances. |
Thanks for this. We should probably turn this into a section in the migration docs. We should also find some way of cleaning up the existing script mappers in the db. |
|
Hi, we deprecated the ability to upload scripts through the admin endpoints quite a while back, which was then finally removed in 18 or 19. Somehow though during this deprecation the SAML protocol mappers where forgotten and they where not disabled like the other parts. The fact that continued working was a defect, rather than expected behaviour. Due to the fact that we consider uploading scripts through the admin endpoints a security risk and that the SAML protocol mappers where left in by mistake we decided these would have to be removed quickly. I appreciate we may not have the best communication around this though and will try to improve on that in the future. |
|
Thank you for the answer. I understand the reasoning, but I was mostly confused by the wording. The changes mention that the admins "should" upload scripts through the server directly. The word "should" implies that there is an option to not use the approach (the word "must" has to be used when a strong requirement is in place). As such, I assumed that any scripts that had been uploaded to the server through the admin console would still be available (and they are in fact still in the database), but read-only, and the option to add new scripts would be disabled. This approach would offer a longer transition period, and would have the added benefit of offering the possibility to delete the old mappers when the scripts are moved to the jar file. I would assume that this would have to be removed at some point, since it increases the amount of code, but Keycloak appears to have a reasonable approach to phasing out in most cases. As a bit of feedback on the user side of things, I think that the mappers should be moved to the |
- 8000
|
Is it safe to delete leftover mappers manually from the database tables protocol_mapper and protocol_mapper_config? |
Uh oh!
There was an error while loading. Please reload this page.
Version 19.0.2 completely disables all Javascript mappers for SAML clients. The release notes mention that going forward the ability to upload scripts through the admin console is disabled; however, the wording does not imply that existing mappers would also be removed. Since this is a breaking change, there should actually be emphasis added to it.
The script upload ability should be slowly phased out - the server developer guide actually mentions the ability to re-enable the functionality using the
upload_scriptsfeature that does not appear to work with Quarkus (written either asupload-scriptsorupload_scripts).@mposolda, @stianst, please advise how the old scripts can be recovered.
All reactions