User has lost their mobile phone (OTP). User's laptop was stolen
(CERT). For OTP it used to be a switch on the User "isOtp, setOtp".
There was no way to turn off any other credential type. FYI disabling a
credential type doesn't mean that the user can just login. If the auth
flow requires a credential type and it is not configured it will either
abort or, if the credential type is optional, it will fire a required
action to set up that type.
On 10/31/16 1:46 AM, Stian Thorgersen wrote:
Can you explain the rational behind this? I don't understand what
the
use-case is and why you would want to "disable" credentials.
On 28 October 2016 at 23:00, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Admin console user credential tab has been changed. It will now list
"disabable credential types". This will be a list of credential types
that can be disabled by the admin (i.e. OTP, PASSWORD, CERT, etc..).
All this hooks into the Credential SPI that I went over a few weeks
ago. So, if new credential types are created, they should show up in
the console too.
Note that disabling happens per credential type, and not per device
(i.e. OTP). I honestly could not figure out how to have an SPI and
generic admin console UI that would take into account ideas like
multiple OTPs, certs, etc...So, disabling is done per type, not
per OTP
generator. These are the SPI items that are the backbone of this
feature. They are methods on UserCredentialManager
/** * Calls disableCredential on UserStorageProvider and
UserFederationProviders first, then loop through * each
CredentialProvider. * * @param realm * @param user * @param
credentialType */ void disableCredentialType(RealmModel realm,
UserModel user, String credentialType);
/** * Returns a set of credential types that can be disabled by
disableCredentialType() method * * @param realm * @param user *
@return */ Set<String> getDisableableCredentialTypes(RealmModel
realm, UserModel user);
CredentialProviders and UserStorageProviders will be required to
implement these methods if they support credential updates.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>