I have been using a local standalone instance of Keycloak Version 2.00 to create some different themes/skins for Keycloak.
This task was successful, and I can login to my local Keycloak server instance and use the Administrator web application skinned as required using a wide variety of browsers.
I have now ported these "proven" Keycloak scheme configuration files onto a Keycloak Version 2.00 + MongoDB Docker container running on a remote Linux host. (Specifically, locating my scheme configuration files under folder %KEYCLOAK_HOME%/themes).
I have found that only a subset of browsers work successfully for this remote Keycloak instance.
Both Firefox and IE work fine. Chrome and Opera do not. I get Java script errors (the Chrome example screenshot shown below, but Opera fails in a similar way) .
I would be grateful to know if anyone else has encountered this issue, and even better what they did to overcome it?
Any help gratefully received,
Crown Commercial Service Supplier
BSI ISO/IEC 27001 certification number IS 585161
Gandlake Limited, a Limited Liability Company registered in England and Wales under number 4667925. Registered Office: Gandlake House, London Road, Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11
Ran into something implementing a user federation example. My user
federation example stores passwords in plain text. So, I wrote a plain
text password hasher. The first time the password is validated, the
hashing iterations don't match from the returned
UserCredentialValueModel. The user fed provider always returns 0
because its plain text. The CredentialValidation class sees that the
hash iterations dont' match with the default realm's hashing iterations,
so the password is rehashed. Rehashed with the default realm
algorithm. There is a bug here in that the algorithm is not set to the
realm's hashing algorithm, so, once a user is validated once, they can
never be validated again...at least in this scenario.
The bigger question is, how do we handle this scenario where the User
Federation Provider does not store passwords in the same format as the
realm's password policy? The workaround is to ignore password updates
when updateCredentialsDirectly is called. But this seems like a hack.
A lot of documentation would need to be in place for this.
I've been unable to figure out how the providers/ directory is created,
implemented, or configured. Hints? It also doesn't seem to deploy
anything you have in the jar you add to providers/. I'm trying to
deploy JPA with it and it doesn't automatically set up.
Anybody know? Or did Stian implement this?