Conditional verify_enrollment token enrolment policy

Question
1

Hello everyone, this is my first question here so I hope not to miss too much stuff…

I tried to search but didn’t really find anything related.

My setup is:

  • privacyIDEA 3.9.3
  • Shibboleth IDP v4 with fudiscr plugin
  • custom PHP webapp for users to enrol and manage their tokens that uses an admin token to interact with PI

So I set an verify_enrollment for SMS tokens so that users have to confirm the number they just set. The token init is done by an admin account through a custom frontend that the final user interacts with. My issue is that I need to be able to add programmatically new sms tokens using SMS numbers I already have (and have been previously verified by other means), without triggering the verification process.

Now, I haven’t found find ways to customize the verify_enrollment policy meaningfully for this. In particular

  • there’s no way (I found) conditionally apply the policy depending on who the admin user enrolling the token is
  • if I set a condition header, I need to send that header with every request, there’s no way (I found) to apply the policy if the header exists and adding an apache rule to set a default value for the header just seems ridiculous to me…

I’ve been using privacyidea for a bit but I couldn’t really find a solution for this…

Thanks in advance!

2

Side note: The fudiscr plugin is not supported by the privacyIDEA project.
It does not implement the full logic of the communication with the privacyIDEA server and rather implements some manual processes.

If you want to make use of verify_enrollment, you should use the privacyIDEA Shibboleth Plugin, which you can find here:

However, do I understand correctly, that you actually set up a dedicated new web application for enrollment? Hm, why not use the selfservice portal? Or why not use the plugin?

I am not sure, if I get your requirement right. So when enrolling the first SMS token, you want to enroll further SMS tokens to the user?
This is very unspecific.
You might want to take a look at the scripthandler.

3

I’m sorry for making confusion. I guess I wrote too much about my setup and less about my actual issue. I’ll still have a look at the shibboleth plugin but in any case that’s not related to my issue, as I’m handling enrolment using a custom web application that is interfaced with PI through API calls.

My (only) problem is, I need to be able to enroll an sms token in 2 different contexts.

  1. By the user, in self-service mode, using the verify_enrolment policy option
  2. By an operator or from an automated system, without the verify_enrolment option (otherwise, the user would receive an sms without having requested it) - no verification would be needed in this case, as it would have been already verified in other ways

In both cases, it would need to be done through an API call to PI using an admin account. In any case there would be just 1 sms token per user, that would be set either with procedure 1 or 2 (described above).

Hope this is now clearer, thank you so much for your time and patience!

4

Missed to reply to this:

However, do I understand correctly, that you actually set up a dedicated new web application for enrollment? Hm, why not use the selfservice portal? Or why not use the plugin?

As said, I’m going to have a look at the plugin. Reason why is I didn’t know about its existence and I followed a tutorial provided by GARR which was using fudiscr.
I’d need to check but the reason why decoupling enrolment from the IDP is that said custom application holds other profile management features that are independent from the IDP itself and as such, is an external component. For sake of keeping the process cleaner and more streamlined for the user, enrolment has been integrated that way.

5

Maybe you are overcomplicating things.

  1. A user can enroll an SMS token. To do so, you do not need necesssarily the verify_enrollment. The user can do this
    a) via /validate/check endpoint and verify_enrollmentor
    b) via the /auth endpoint and then using the JWT via the /token/init endpoint.

  2. An administrator or operator can enroll a token for another user via the /auth endpoint, and then using the JWT via the /token/init endpoint.

Note, that a user can use all the endpoints and always enroll tokens for himself.
An administrator can use all the endpoints and always enroll tokens for others.

https://privacyidea.readthedocs.io/en/latest/modules/api/auth.html#post--auth

https://privacyidea.readthedocs.io/en/latest/modules/api/token.html#post--token-init

More on admins:
https://privacyidea.readthedocs.io/en/latest/faq/admins.html

6

Thank you for your reply.

I think I still didn’t manage to explain my point. I’m indeed using /token/init to enrol sms tokens, both in case of user initiated or admin initiated enrolment.

The point is that I need the verify_enrolment in case of /token/init issued by users, but I need it not when it’s done by an admin. My point is, the verify_enrolment policy option (for what I understood) is applied too generically and I didn’t find a way to apply it just when it’s the user that enrols, disabling it instead when it’s the an admin that inits the token…

7

If anyone has this same issue, in any case, I managed solving in this awful way:

Inside apache httpd config:

    <Location /possible-pi-path>
      RequestHeader setIfEmpty X-PI-Disable-Verify "false"
    </Location>

Then setting the token enrollment policy with a condition that enables the policy when X-PI-Disable-Verify header is different than true.

8

Since verify_enrollment is an enrollment policy, there is currently no possibility to differentiate between the user enrolling the token and an administrator enrolling the token for a different user.
The ugly workaround with an extra HTTP header is currently the only option i can see.

1 Like
9

Can you a bit more explain, why a user or an admin would enroll a token for the user?
So an admin would enroll an sms token and you would trust the admin to enter the correct phone number? But not the user?

What would be your default enrollment scenario of both and in which cases would there be a backup enrollment scenario?

10

As I pointed out previously, I have only 2 enrollment scenarios.

  • A (default): User enrollment, initiated by the user, for themselves, who inserts the phone number and has to be verified;
  • B (backup): Operator enrollment, initiated by an admin user, for a normal user. In this case the number is trusted and needs not to be verified.

Use cases:

  • A: A regular user logs in and wants to change their phone number. They input the new number and receive the SMS for verifying it.
  • B: A regular user has troubles with MFA (e.g. cannot enter the MFA area because they only have SMS as their token and they changed/lost number, or they’re in a situation where they need to perform MFA but for any reason cannot use tokens they have) so they contact support helpdesk. The helpdesk operator, logged in as an admin, enrolls a new number without verification.

Hope this is now more clear.

11

As Paul mentioned, this is not possible the way you want it.

However, if the user contacts the help desk and the help desk created the token, the helpdesk could as the user, “please give me the OTP value, that has just been sent to you”.

12

I actually achieved it through headers conditions, even if it’s quite suboptimal, I’ll leave it like this. However I don’t think my use case can be considered particularly exotic…