How many fields need to be read from the database, is everything in a single field?
3 fields more (name, email, address) my problem is that the password coding in my database is configured with MessageDigest hasher = MessageDigest.getInstance ("SHA1"); and the result is different from the one that the scram-mapper returns,
its possible set a custom password encode?
So are you saying all three of those fields are involved in the handling of the password?
Not only one, but the way in which the password is stored in the database is with MessageDigest.getInstance ("SHA1") and when I set up custom-scram-sha-1 the result is different, it is possible to customize the sending of the value of the password or what could I do
We do have support for the "simple-digest-sha-1" password type anyway which should just be a simple SHA1 digest without salts, this should be definable from the 'simple-digest-mapper' on the principal query.
Thanks, I'm going to perform that test, and is it possible to have a custom mapper that is implemented from my code? since the database's password is implemented with personalized encryption
It should be possible to develop a custom Password within the PasswordFactory SPIs provided it can take the same set of parameters as supported by one of our other mappers, this may be something interesting for us to see if we can assemble an example.
Great, I'm going to do the PasswordFactory investigation so that the password comes encrypted from my code, I will be commenting on how the test is going
Hi, I had the exact same requirement of a custom password implementation in the JdbcSecurityRealm. I also did the PasswordFactory investigation, and I'd like to share my results. Here is what I did:
1. Write a custom implementation MyPasswordFactorySpiImpl which extends PasswordFactorySpi
2. Write a custom java.security.Provider named MySecurityProvider to add the MyPasswordFactorySpiImpl
Here I stumbled over some limitations regarding the algorithm identifier of my custom password handling. Even though I could register any custom algorithm with the Provider, it would be of no use because the wildfly-elytron integration is very strict when it comes to algorithm selection. In org.wildfly.extension.elytron.JdbcRealmDefinition.ScramMapperObjectDefinition only four algorithms are allowed to be configured. So I have to pick one of them when I register my custom MyPasswordFactorySpiImpl with the MySecurityProvider (i.e. I kind of override the PasswordFactorySpiImpl that was registered by the WildFlyElytronProvider).
3. Put my custom provider in a module and place it in $JBOSS_HOME/modules/...
4. Register the Provider in the section of the elytron subsystem using
5. Adding the provider to the existing "combined-providers" provider at first place to make sure, the elytron provider comes after my custom provider (so that the override mentioned above may work)
During startup of Wildfly my custom provider is registered and indeed takes first place in the list of all registered providers. But when it comes to actually getting a PasswordFactorySpi from the providers (in org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper.map(ResultSet, Supplier<Provider>).passwordFactory) my custom provider is gone and for the selected algorithm the original PasswordFactorySpiImpl from WildFlyElytronProvider is used. The reason for this may be that when JdbcSecurityRealm is created by JdbcSecurityRealmBuilder the list of providers is by default comming from org.wildfly.security.provider.util.ProviderUtil.INSTALLED_PROVIDERS (which leads to Security::getProviders). So the whole custom provider registration mechanism of step 4 and 5 is bypassed. There is a setProviders() method in the Builder which may be used to set other providers but this method never is called. All in all, providing a custom PasswordFactorySpi did not work for me. Either I missed some importand link of provider to JdbcSecurityRealm in the configuration or there is a bug.