Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Attributes #680

Open
foot3print opened this issue Apr 12, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@foot3print
Copy link

commented Apr 12, 2017

Hi to everyone!

MySetup:

My privacyIDEA server should perform the 2FA (TOTP/EMAIL) of Users through the ssh plug-in.

privacyIDEA: 2.18.1
Installation method: Ubuntu Repo
OS: Ubuntu 16 Xenial
Webserver: Apache2
Tokendatabase: default from Package- mysql

What did you try to do?

  • I only use 1 userstore (LDAP) as backend of privacyidea for my users. I have 2 auth policies, each to cover for the policies i need.

Policy-1 ## this is for every PI Authentication from users within my_realm
Policy Name: main_auth
Scope: authentication
Action:
{ "emailtext": "This is your one time password: valid for 180 seconds.", "reset_all_user_tokens": true, "emailsubject": "OTP for 2FA", "otppin": "userstore", "emailautosend": true }
Realm: [ "my_realm" ]
Resolver: [ "ldap_resolver" ]
User: [ ]

Policy-2 ## this is for PI Authentication of admins listed admin_auth > User
Policy Name: admin_auth
Scope: authentication
Action:
{ "emailtext": "This is your one time password: valid for 180 seconds.", "reset_all_user_tokens": true, "emailsubject": "OTP for 2FA", "otppin": "userstore", "emailautosend": true }
Realm: [ "my_realm" ]
Resolver: [ "ldap_resolver" ]
User: [ "admin1","admin2"" admin3" ]

Policy for WebUI
Action:
{ "default_tokentype": "email", "tokenwizard": true, "remote_user": "disable", "login_mode": "privacyIDEA", "logout_time": "180" }
The rest of the parameters are same as above (ldap_resolver,my_realm,user[])

This works in my setup. The admins are able to login with their credentials and prompted with the "tokenwizard" to enroll the first token. After this, the user will be forced to log out and log in again but with the 2FA (default email) as the token for challenge response.

What outcome did you expect?

Can we possibly add a Checkbox/enable-disable Option for a user-parameter like "auto_enroll" to enable or disable autoenroll? Since my privacyidea server always authenticates against itself (not userstore) this Option will make it easier for me to enable access for Users who applies for 2FA in my_realm and disable per Default the 2FA for users who does not have tokens and is not enabled for auto_enroll/token enrollment.

Respectfully,
JB

@cornelinux

This comment has been minimized.

Copy link
Member

commented Apr 12, 2017

Hm, I am not sure, if I understand your expected outcome.

You configured a webui policy that defines, that a user should login by authenticating against privacyIDEA.
I think you are using the term "autoenrollment" in a different way, than I do.

Nevertheless:

If you want to authenticate users, who have no token, yet, against the user store, you can configure a passthru policy.
http://privacyidea.readthedocs.io/en/latest/policies/authentication.html?highlight=passthru#passthru
This way, the user, who has no token, can authenticate with his userstore password as long as he has no token. Does this fit your needs?

@foot3print

This comment has been minimized.

Copy link
Author

commented Apr 13, 2017

@cornelinux

Oh I forgot, I've configured the "otppin" to use the userstore. Sorry for the confusion, I was thinking about my script after the pam_python.so privacyidea_pam.so. I was talking about the tokenwizard. Yes, it does this already. The user, who has no token, authenticates with his userstore password and is directed to the Tokenwizard to enroll his first token. By default, the users can only enroll e-mail tokens after which will be logged out. The User will have log in again and will be required to input the e-mail otp sent to the users e-mail.

To limit the users who are configured to have the tokenwizard after authenticating against the privacyidea server with their userstore password, I listed them admin1, admin2, admin3 for example in the User under the admin_auth Policy-2 which has passthru:userstore (i forgot to paste this above Policy-2). This setting will only affect the following users in the User list.

--The expected outcome--
Per default, all users from the userstore should authenticate against the privacyidea server, whether per WebUI or SSH. Users who wanted access to 2FA System should mail me first for them to have access to the tokenwizard(as stated above). For this, I could list them in the User under Policy-2 one by one, which is what I am doing right now. Is it possible to have an extra Field for tokenwizard or something like that, that could be enabled or disabled(per default)? That would bring me to just one Policy for all my userstore Users and just enable the tokenwizard to those who wanted access to the 2FA System and create/manage their tokens.

Thanks!

@foot3print foot3print changed the title Feature request: auto_enroll field for user Feature request: tokenwizard on/off field for user Apr 13, 2017

@cornelinux

This comment has been minimized.

Copy link
Member

commented Jun 23, 2017

This would be an additional option for the user, who is not stored or managed in privacyIDEA.

So we would need an additional table like user_option to add additional information to the user from the LDAP or any other user source.
One of these options could be "login WebUI" or "enrollment wizard".

Then we need policies or event handler to interact with the values in this user_option table.

@cornelinux

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

Here is another thing:

The tokenwizard is displayed under certain conditions, if the user logs in to the webui. So there is no difference between the webUI and the tokenwizard.

Is it OK, if - for simplicity - I speak of the webui?

So your requirement would be:

Only allow users access to the web UI, if they contacted you and you granted them access.

If you are using LDAP or Active Directory, this is already possible today:

  • Create a security group in your AD called somehing like privacyidea_webui_users.
  • If the user calls you, you can put the user object in the privacyidea_webui_users group.

Now to the privacyIDEA part:

  • configure a realm, that contains two resolvers:
    1. The common resolver, which finds ALL users and then
    2. a special resolver, which finds users in the security group privacyidea_webui_users.
  • set the special resolver to higher priority in the realm. If a user object in member of this group this resolver will be used.
  • Now define one policy that matches the special resolver and grants access to the webui.
  • Define another poolicy, that matches if the user is not member of the speical resolver and set webui login=None.

This should(TM) have the expected effect: Only if the user is member of the group he can login to the webui. Normal users can not log in.

Thoughts about user attributes

User attributes should be attached to users. At the place where the user is managed - in the IdM. This would be the Active Directory or LDAP.
You want to define access controll/ access rights - but based on what? Usually not on a user attribute, since privacyIDEA is not the place where you would categorize users. This is what an IdM is for.

So I am a bit reluctant to add user attributes to privacyIDEA. I can understand your requirement, but I am not sure about, what is the best solution.
I you have access to LDAP/AD, then I would recommend the path as described above.
If not, I understand, that you want to do the access in privacyIDEA.

Another thought: Maybe instead of adding attributes to the users, we could group the users manually (well in fact this would be the attribute memberOf ;-)

So to take the next step, I need some more of your input!

@cornelinux

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

This might be related to #710

@foot3print

This comment has been minimized.

Copy link
Author

commented Oct 19, 2017

Hi,

I commented a topic related to this in the community site here:

https://community.privacyidea.org/t/privacyidea-internal-user-attributes/532

However, if the relevance and importance is too vague, you can close this ticket. Thank you.

Regards,

@cornelinux cornelinux changed the title Feature request: tokenwizard on/off field for user User Attributes Aug 7, 2018

@speedy01

This comment has been minimized.

Copy link

commented Sep 6, 2018

@cornelinux
per this thread https://community.privacyidea.org/t/qr-code-via-sms-or-email/793/2 ; Id like to +1 an internal attribute for mobile numbers. use case: I could send QR code {googleurl_value} to an end users via SMS. This will be used if a mobile number is not in ldap, or if there needs to be an override. There would be no need to store or keep the sms number, as it would be used as a one time delivery method for the created token. perhaps only make the field visible if a SMS provider is configured to reduce confusion..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.