privacyIDEA internal user attributes


#1

We have a feature request here.

To me it boils down to:

“Hey, I need to add additional attributes to the users in privacyIDEA”.
Although my users are located and managed in another source like LDAP or Active Directory.

So here is my question: Who would want to manage user attributes in privacyIDEA. For what reason. I am looking forward to your scenarios.

Thanks a lot
Cornelius


#2

Personally, I think that’s feature creep that also decentralizes user data. But I obviously don’t have a valid usage case.


#3

Thanks. I see it similar. Unless I see a more abstract scenario, which would allow for a wider range of (yet unknown) use cases.


#4

Hi,

hmmm, i think i was also wondering about if this would be possible and to what scnenarios would this be applicable.

As for a scenario, maybe addtl user attributes can address the following:

  • your organization has >5000 users
  • users are managed in ldap
  • you are not allowed to modify in ldap??
  • not all users should do two factor auth
  • the auto- enrollment wizard should only be accessible to users who are tagged as ‘those who must use 2fa’
  • other users should not be able to login to the PI WebUI
    In order to make the handling super easy, one can just tag a user attibute as 2fa active therefore enabling the wizard for the user upon successfully logging in.

NOTE! - Maybe this not conventional or even logical, and maybe this can already be done by Events_Handler or in LDAP itself. Please do correct the thought in any case.

Regards,


#5

Thanks for your input!

I think the question is:

Based on what should a user to 2FA or not?

And the next question would be:

Who is allowed to decide, if a user has to do 2FA or may do self enrollment?

I don’t think, that I am currently fit to answer this questions. (Especially not for everbody).


#6

In this scenario, lets say 50-100 users should/must do 2fa. These users can be dynamic, which means that they could come and go for example. The tokenwizard/self-enrollment will be available for these users if they still don’t have a token. Actually, this can also be done through the policies and configuration of the ldap resolver using ‘Search Filter’. There we can input the users who are supposed to do 2fa. But this can be cumbersome if we keep on adding and removing entries in the filter list.

Since we are able to list all the >5000 users in ldap, the thought of having another attribute or a flag which the Helpdesk could just tag on or off came in.

Of course there may be other ways to make this easier or more comfortable.

– edit –
PS. I was browsing a few topics here and remembered i tested this in relation to ‘autoenrollment email/sms’. I was able to configure the system to do autoenrollment through event handlers, passthru, tokenwizard. The gist is that all users should be able to do autoenrollment via email/sms FIRST, only if a trigger is on --> this is the addtl attribute??

Regards,


#7

So again - who as a person decides it a user can do this. Then it would be the token administrator.
Why would you add and remove entries in the filter list?

If there are more than 5000 users, you probably have an IdM. And usually this would be a task of the IdM. Then this “flag” would be an attribute in the LDAP? I am digging a bit to understand if there is a cool, sensible thing we can add to privacyIDEA, and if - why and how we add it in a way that it can be used for many scenarios.

So this would mean, if you have an additinoal user attribute in privacyIDEA, then the policies should also be capable to match on this user attribute.


#8

yes, actually the case szenario would be null and/or better if the attribute would be in ldap, then problem solved! The problem arises if one can not (for some stupid reasons) add attribute to the idM.

yes the additional attribute should also be capable to match the policies. I am not sure if this case would be a good example actually or even reasonable. Im sure other privacyidea users could give other sensible szenario/s to this discussion.

Regards,