Conditional verify_enrollment token enrolment policy

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!

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.

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!

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.

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.

More on admins:

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…