Hi,
does Keycloak have any APIs where a 3rd party server side application, like our IDM User Self-Service, could register credentials for a user or test credentials for a user?
The Admin API allows to reorder/rename/remove credentials, but not to add them, if I got that right.
I’m looking especially for TOTP and WebAuthN credentials.
Register WebAuthN: Either my application or Keycloak should provide the challenge. My Application would do the registration on the client side. I’ll then just tell Keycloak “this is the challenge and the WebAuthN registration data for User X”.
Test WebAuthN: Either my application or Keycloak should provide the challenge. My Application would fetch a List of client credentials and do the login on the client side. I’ll then just tell Keycloak “this is the challenge and the WebAuthN login result data for User X - is it valid?”.
If I understood your question correctly it is a similar issue as Keycloak API Rest - check if password is correct .
Also, messing with the registration flows, as they are browser based, could cause login issues. The registration should happen within Keycloaks native flows.
It’s not really the same. I want to be able to write the management interface my own, because we have very special needs and already have a self-service interface. But I don’t want to deal with the crypto part of validating WebAuthN credentials.
I’m also looking at software like PrivacyIDEA which does allow to do that.
It’s also important to me because I want to be able to import/export WebAuthN credentials between systems, like different Keycloak instances or PrivacyIDEA just in case.
I know that I can use required actions to direct the user to a credential enrollment, but that’s not that helpful in my case.
It’s not really the same. I want to be able to write the management interface my own, because we have very special needs and already have a self-service interface. But I don’t want to deal with the crypto part of validating WebAuthN credentials.
It is again an issue of using Keycloak without using Keycloak.
We just trigger the CONFIGURE_TOTP required action (kc_action:CONFIGURE_TOTP in login request). You can style the page or if you need additional code in Keycloak Backend you can also extend org.keycloak.authentication.requiredactions.UpdatePassword and provide your own implementation (just use the same provider id and return a higher order)
@Override
public int order() {
return super.order() + 1;
}
Why do you think wanting to import TOTP/WebAuthN credentials from another system / having an API to enroll credentials for other users (which we may want to do with credentials our IT department hands out to employees) is an Issue of “not using Keycloak”?
These are things you might want to do in an enterprise environment and I don’t expect Keycloak to have perfect UI and flows for that, but having an API that can be used for something like that would be nice.
Just because some other products doing something, and just because you expect something to be available, it’s not necessarily the proper approach or an approach which every other product has to follow. As already mentioned, Keycloak does not support the approach to offer APIs for everything, as this makes not always sense.
Storing credentials in other systems might(!!!) be one approach, although I don’t like it. But I currently have the same challenge, where there are already credentials stored in a FIDO server and these credentials should also be used when these users authenticate via Keycloak. Exporting and Importing credentials is IMHO(!) very bad practice, as it leads often to mistakes and errors. I’m currently implementing a proper authenticator for this challenge, which fetches the challenge from the FIDO server (it is offering such an endpoint) and pass it to the users browser. After the user did the authentication and sends back the signed challenge, I’m passing it to the API of the FIDO server, which is able to verify the signed challenge response. IMHO a much (c)leaner approach than ex-/importing data.
Basically it’s the same approach the UserStorageSPI uses in the isValid() method. There, one has access to the cleartext(!!) password and can forward it for verification to the external storage (hopefully through an encrypted connection). This is also done this way in the LDAP implementation. Also here, no credentials are ex-/imported, the credentials remain at the originating system.
When external systems manage the credentials, they should continue to do so, having different systems managing credentials will lead to mistakes, errors and in worst case, to data breach, if not done properly. Especially if you try to ex-/import data. So, simply don’t do it.
I’m working in an environment where I have to sync user-data between oracle databases, few LDAPs, two active directories and services like Azure. Syncing a credential, especially a publik key one, is not really challenging.
But yeah, I don’t plan to sync all credentials permanently between many stores. Ideally you have one credential store only - but one that allows you to migrate credentials to another store if you need to in the future.
Also the “enroll credential for user” option requires this kind of access.
Thing is, I may need PrivacyIDEA in the future. I now do have keycloak though and I want to enroll WebAuthN 2FA asap. So I want to make sure if I decide to use KC now and migrate to PrivacyIDEA later (as credential store), I can do this without starting over.
From the chapter “Things that are technically possible, might not always be a good idea”:
Keycloak offers with its SPIs a usable extension platform. One is able to extend the server with interface implementations and offer the desired functionality, also API endpoints…
End of my three cents to this topic. Everything is already said.
Just because some other products doing something, and just because you expect something to be available, it’s not necessarily the proper approach or an approach which every other product has to follow. As already mentioned, Keycloak does not support the approach to offer APIs for everything, as this makes not always sense.