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

Fallback for multiple active/enabled tokens #682

Closed
foot3print opened this issue Apr 13, 2017 · 4 comments
Closed

Fallback for multiple active/enabled tokens #682

foot3print opened this issue Apr 13, 2017 · 4 comments
Labels
Type: Question Issues from 'are You lost' template

Comments

@foot3print
Copy link

foot3print commented Apr 13, 2017

My Setup

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?

What I would like to do is to disable all tokens except the default (email) upon authentication, if the user has multiple active/enabled tokens. Then use the default token for the challenge, which is the email token.

PIN for Tokens are disabled for user enrollment and "otppin" is set to userstore.

I tried this using the Event Handler:
Events: [ "validate_check" ]
Handlermodule: Token
Conditions: {"token_has_owner":"True","tokentype":"totp,sms","user_token_number":"3"}
Action: disable

What outcome did you expect?

The expected outcome would be to use only the default Token after authentication against the userstore, since the user has multiple active tokens.

What outcome did you experience?

It fails with the message on the log:
Multiple tokens to create a challenge found!

Log file

[privacyidea.lib.tokens.smstoken:191] Exiting is_challenge_request with result True
[2017-04-13 13:50:09,000][2110][139733153937152][DEBUG][privacyidea.lib.token:191] Exiting check_token_list with result (False, {'message': 'Multiple tokens to create a challenge found!'})
[2017-04-13 13:50:09,000][2110][139733153937152][DEBUG][privacyidea.lib.token:191] Exiting check_user_pass with result (False, {'message': 'Multiple tokens to create a challenge found!'})
[2017-04-13 13:50:09,001][2110][139733153937152][DEBUG][privacyidea.lib.policy:179] Entering get_action_values with arguments (<privacyidea.lib.policy.PolicyClass object at 0x7f1613c00e50>,) and keywords {'action': 'auth_max_success', 'scope': 'authorization', 'client': '192.168.1.12', 'realm': u'ldapmain', 'user': u'admin1'}

Conclusion rather Questions

  1. Can I accomplish this using event handling?
  2. Can we assign values like ">3", "<10" in the condition "user_token_number"?
  3. How can I do this? The User gets locked out if he has multiple active tokens and the tokens to do challenge-response is set to "totp email sms"

Thanks for your help! :-)

@cornelinux cornelinux added buy this feature Type: Feature request A change requested or proposed by a user which is not on the default roadmap Type: Question Issues from 'are You lost' template and removed buy this feature Type: Feature request A change requested or proposed by a user which is not on the default roadmap labels Apr 13, 2017
@cornelinux
Copy link
Member

@foot3print Reading this again, I realize I am not quite sure, what you try to accomplish.

What I would like to do is to disable all tokens except the default (email) upon authentication, if the user has multiple active/enabled tokens. Then use the default token for the challenge, which is the email token.

Please shed some more light on this. You can use these questions to provide more details:

  • Should the user be allowed to have several tokens?
  • If the user is allowed to have several tokens, why should he not use these for authentication? For what would he use these tokens then?
  • Who enrolled the tokens for the user?
  • Why should the user not use other tokens for authentication? Why does he has the tokens in the first place?
  • Where does the user authenticate with these restrictions?

@foot3print
Copy link
Author

foot3print commented Apr 20, 2017

sorry for the confusion, i am setting up a privacyidea server which will authenticate the user against the userstore backend (ldap/krb5) and also provide the second factor authentication. This ticket is actually a follow up question to the Setup in my previous ticket -- https://github.com/privacyidea/privacyidea/issues/680

Q- Should the user be allowed to have several tokens?
Q- If the user is allowed to have several tokens, why should he not use these for authentication? For what would he use these tokens then?

  • Yes, users are allowed to use several tokens. However, my Setup does not use PIN for each token and instead uses the userstore using the parameter in the policy: authentication { "otppin": "userstore" } . This approach is to avoid a lot of PINs for different tokens to be memorized by the users.

  • Since all tokens have no PINs, the user just types in the 6-digits one time password when prompted, after the first authentication(against privacyidea but with ldap backend). But the problem here is that everytime a user has multiple tokens available and activated/enabled, the system returns this error and does not proceed with the authentication further:

/var/log/auth.log
Apr 20 12:18:36 twofactor sshd: Authenticating baluyot against https://twofactor.defrealm.com
Apr 20 12:18:38 twofactor sshd: requests > 1.0
Apr 20 12:18:38 twofactor sshd: privacyidea_pam: result: {u'status': True, u'value': False}
Apr 20 12:18:38 twofactor sshd: privacyidea_pam: detail: {u'message': u'Multiple tokens to create a challenge found!', u'threadid': 139733137098496}

/var/log/privacyidea/privacyidea.log
[privacyidea.lib.tokens.smstoken:191] Exiting is_challenge_request with result True
[2017-04-13 13:50:09,000][2110][139733153937152][DEBUG][privacyidea.lib.token:191] Exiting check_token_list with result (False, {'message': 'Multiple tokens to create a challenge found!'})
[2017-04-13 13:50:09,000][2110][139733153937152][DEBUG][privacyidea.lib.token:191] Exiting check_user_pass with result (False, {'message': 'Multiple tokens to create a challenge found!'})
[2017-04-13 13:50:09,001][2110][139733153937152][DEBUG][privacyidea.lib.policy:179] Entering get_action_values with arguments (<privacyidea.lib.policy.PolicyClass object at 0x7f1613c00e50>,) and keywords {'action': 'auth_max_success', 'scope': 'authorization', 'client': '192.168.1.12', 'realm': u'ldapmain', 'user': u'admin1'}

Q- Who enrolled the tokens for the user?

  • Users can enroll tokens.
    Q- Why should the user not use other tokens for authentication? Why does he has the tokens in the first place?
  • Each time a user enrolls a token, it is per default enabled. Since the second authentication (challenge/response) does not proceed if the user has multiple tokens for the challenge-response, I thought I could do a workaround here to disable the active tokens and just enable the email token (default) and provide the user additional information through the Event Handling --> If Conditions are true --> then send email Notification to the User with the additional information that he/she had many active/enabled tokens available for the challenge/response, thus, still providing a way to do 2FA against the server instead of being locked out because of multiple tokens enabled. Currently, the Setup fulfills what it is supposed to do(2-factor authentication against the privacyidea server with ldap backend) only if the user has one token active/enabled. Users can use either one of their tokens for the authentication. In short, I'm looking for a way to have a "Fallback" in case the user has several tokens enabled. As of now, I'm playing with the "Event Handling" and some script to see if I could get this setup right.

Did I made it clearer this time? I hope this make sense. ^,^

@foot3print
Copy link
Author

  • after trying a couple of Event Handling and workarounds, i was not able to accomplish this. The problem as what I experienced is the following:
  1. The TOKEN does not get disabled even if there is a event-handling in which ACTION should be to disable the TYPE of token after the authentication succeeds.
  2. In my opinion it would be better if the user_token_number in the conditions can also accept statements such as if user_token_number '>1', '<5', or such.
  3. Another parameter in the conditions could be user_token_active??

Therefore, I would close this fore the mean time unless anyone had better experience or has other ideas?

@cornelinux
Copy link
Member

If the user first enters his LDAP password (against privacyidea) and in a second step his OTP value, this is a challenge response. Multiple tokens were not supported with challenge response. This will be changed in 2.19. There is a closed issue in the milestone 2.19.

As far as 2. and 3. your ideas about the event conditions is concerned, this sounds interesting. Please open an issue for each of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Question Issues from 'are You lost' template
Projects
None yet
Development

No branches or pull requests

2 participants