Passthru on first X login attempts

Question
1

Hi everyone!

I successfully installed PI and integrated it with a Citrix gateway. I am currently struggling with the process of enrolling tokens to new users, since I do not want to publish the PI’s webinterface to public internet due to security reasons.
I would like to implement the logic “allow the first X login attempts without second password”. The policy action passOnNoToken almost does what I want, except that if a user doesn’t enroll its token, he/she would be able to login without MFA forever.

I thought, one way to solve this would be a custom user attribute: on the first login, attach this attribute to the user. But for some reasons, there is no event handler userinfo.

I also noticed that there is a counter module. But if I understood the documentation correctly, these counters are global and not bound to a user-object. I have found no way to attach a counter to a user…

Does anybody have a solution to my problem / is able to point me into the correct direction?

Thanks in advance!
Martin

2

Did you listen to the German podcast “Login Success” about rollout concepts?

I think what you actually want is easily achievable if you take one step back.
As far as I understand you want to allow a user to login with one-factor (static password) for a certain number of logins or a certain time and then actually cancel the availability of this 1-factor-login.
If the user did not manage to enroll his 2nd factor during this period, this would be his problem.

You are right, the generic passthru mechanism does not work out here, since it is not flexible enough.

I would suggest the following:

  1. enroll a static password token TokenA to this user. This acts as the 1-factor authentication as long as the user did not enroll a real 2nd factor.
  2. You can either limit the amount of allowed logins (use this static token only for 10 logins via event handlers) or by a validity period.
  3. The TokenA will be rendered invalid or deleted if it is used more than this specified number/period. The user will end up with no Token and thus will not be able to authenticate anymore.
  4. If the user however manages to enroll a real 2nd factor TokenB, then an event handler can delete the still existing TokenA of the user.
  5. The user ends up with a TokenB as a real 2nd factor.