Resolver and User token relation

Hi @cornelinux,

I have some question regards the resolver and user token relation.

We use a few resolvers to fine tune policy, specifically they are all ldap resolvers with different filters. However, users may move from one resolver to the other from time to time due to their change of status, for example. When the users change to a different resolver, their token become unbound as the token stay with the resolver; as a result, the users lose their token.

This become inconvenient and disruptive to user experience. I wonder if there is a way to avoid this? If there is an option available somewhere to allow the user to keep their token when they move to a different resolver of the same realm?

Thank you!

Hello @quynh,
is it not possible that a user keeps a token when the user is moved to another resolver.
If you take a look at the database schema, the token is actually assigned to a userid within a resolver.
The resolver in privacyIDEA is the fundamental and generic concept of identifying a user.
From a resolver perspective there is no difference, if you move a user in an LDAP into a different LDAP group or if you would move a user from LDAP to a flat file.
For privacyIDEA this is a different user object.

But what you are actually asking from a top level view is:

How can the a user have certain chainging attributes and depending on these attributes match different policies.

I think this is a very interesting idea, but I would like to address this in a more generic way (So that it works for resolvers and users in general and not only for LDAP resolvers).

I think this could result in using user attributes from the attribute mapping in the policies.
We already do something similar in the FreeRADIUS plugin.
You can map:

 {"groups": "memberOf"}

and in the FreeRADIUS plugin you can match the groups to add the group values to certain RADIUS return values and thus put the user into e.g. certain VLANs.

I could think of something similar for policies and this way you would be much more flexible, since a user can have a list of values in memberOf.

But it is early in the morning and this is only a first idea…
Maybe you also have some more aspects.

Kind regards

Added an idea issue for tracking