Is there a possibility to limit the number of simultaneously enabled tokens per user?
Currently it is possible to limit the total number of tokens per user in the enrollment policy but this does not address my use case: my users need two tokens to work (certificate and totp) and I want to leave them free to recreate a token if they need but only after having revoked the existing one. Otherwise they would just keep on creating new TOTP tokens when they loose or give away their phone without ever revoking the obsolete tokens.
I don’t want to allow 3 tokens (although I do it in practice sometimes) because I want to be sure that the tokens not needed anymore get revoked.
Let’s take the example of a TOTP saved on a smartphone: the user gives his smartphone to a friend or to his child without cleaning it before, the totp token ends up being with someone who should not have it. As my users need to use the services protected by privacyIDEA, they will eventually come to me to have their totp token removed so they can enroll one on their new smartphone but this is not the preferred solution.
Also an important thing is that deleting does not imply revoking: I think that in the case of a totp token, deleting it implies it is revoked but this is definitely not the case with a certificate as deleting it does not trigger the revoke action. So giving the users the right to delete their token would not help me, as e.g. in the case of a certificate, they would rightly be denied to create a new one by openssl (email address already used).
In fact, in an ideal configuration, I would like to be able to say that user A is allowed to have one valid certificate and one validTOTP token while user B is allowed to have one valid certificate, a valid totp and a valid printed list of otps.
So you would even have users with max two (active) tokens and some users with max three (active) tokens?
Could you even configure this in a policy? I.e. can you distiguish those users based on the resolver, they are located in?
(Note to self: userattributes set with a new event handler module?)
Currently I could not easily distinguish the users based on the resolver (ldap in my case). Let’s say that the default use case is one totp + one certificate but there are some exceptions granted on a case-by-case basis. Those exceptions can only be handled at user level, not at any group level. Still, one could think about an attribute to put in the ldap directory and create a resolver that filters only users with this specific attribute present but it would not be easy to manage.