Querying Existing Token for a user with user_fields

Hello everyone,
In our web application’s login flow, we are planning to MFA using privacyIDEA.
I looked at REST API documentation and found an API that can find existing tokens assigned to the users.

I am trying to query that API (using admin user’s token) with user_fields parameter.
We are using HTTP user resolver so users reside in separate database and federated systems, that can be accessed via our REST services.

This is the example of privacyIDEA API that I am looking to use to get existing tokens issued to a user (who’s currently logging in)

curl --location --request GET 'http://127.0.0.1:5000/token?assigned=true&active=true&type=email&user=mfa@example.com' \
--header 'PI-Authorization: <admin access token>'

Question:
My understanding is if the user has two tokens for multiple phone numbers OR multiple emails attached to the token (not dynamically), then you can query one token for a user along with email or phone as input.
But I am not sure, how can I query on ‘user_fields’. Can I see an example on how does this work?

Appreciate all the help!

I thikn your workflow sounds…
…unusual. (see 6.1. Authentication Modes and Client Modes — privacyIDEA 3.6.2 documentation)

What do you actually want this information for?

Thanks @cornelinux for providing reference link.
Some additional points regarding our workflow…

  1. Our users are federated into mutiple external systems, which we are authenticating by calling their REST API. so we dont have a way to create and enroll token per user during user creation itself. As a result, we plan on creating the serial token (and assign to user based on username and user’s contact registered into the system) on user login attempt
  2. Our usecase indicates that we may have a user with multiple emails. On every login, we need to ask users on which email do they want to receive OTP. Once confirmed the email by user, we need to send email OTP via privacyIDEA. So here I was thinking to use /token endpoint (as listed in original thread) to see if token is already created and assigned to this user, then use that token to trigger the challenge (/validate/triggerchallenge). However, we may need to find a token not just by username, for that specific email as well where he/she wants to receive OTP (after user confirms a particular email). So I am looking to see, if I can query the specific token for a user out of many that matches with same email and then trigger challenge. As I noticed, http user resolver expects the single email or phone in response.
  3. Do you see this can be handled in another way?
  4. Do you think we don’t need to check existing token but just create new serial token on every login attempt and trigger a challenge off of that new token?
  5. Do you think this integration using REST API is not the ideal way to go forward with?

Appreciate your recommendations.

privacyIDEA does not do this out of the box, since this is information disclosure.

Also: This email address is (usually) not a userinformation, but a setting of the token.

Thanks again for your inputs @cornelinux .
In that case, what and how we can use user_fields parameter in the request? Can it search on certain attributes related to a user (being set via http resolver)? If so, what would /token request look like if we have to search on certain user attributes?

You explained your expected workflow in a bad way. But that is a common problem, that people are not able to explain unambiguously what they want.

Here is what I think you want:

  1. users log in with their username and password to your portal.(information you did not provide, which I filled in by guessing)
  2. in the first login, when the user has no token, you want to enroll an email token (information you did not provide, which I filled in by guessing)
  3. The user can have more than one email address
  4. You want to ask which email address to use…
  5. …for creating a token and sending OTP values to in the future (information you did not provide, which I filled in by guessing)

Am I guessing right?

One token only has one email address.

A user can have several tokens. Each one has an email address.

If a user has several tokens, depending on the OTP PIN an OTP value gets sent to all of the tokens/email addresses.

Please get your explanation and questions straigt. I do not wan to spent any more time, figuring out in a long discussion what you want.

Thanks again for your answers and explanations @cornelinux
What you thought you guessed is exactly correct.
But I questioned one thing, which still remains unanswered. How to use user_fields? I don’t find any useful documentation explaining how & when this can be used?

Additionally, you explained

If a user has several tokens, depending on the OTP PIN an OTP value gets sent to all of the tokens/email addresses.

What I understood from this is, same OTP value is being sent to all of the user’s email addresses. But I found that a different OTP value is being sent in this case to each email on triggering a challenge. Is that expected?
So I felt communication is not just one way problem here, but both ways. I have been exploring this tool for implementing it right way.
Even when we send OTP to user’s every email address, we would expect OTP to be same (being sent to every email) so that user does not get confused on which OTP to be used for OTP verification.

My questions are probably very basic & obvious, but it’s probably because I am not finding enough information on the workflow with privacyidea. Existing documentation is making a lot of things clear on how to call and integrate with privacyIDEA, but I am missing on “When to use What?” for the workflow/use cases one may have to create.

With that said, I appreciate you taking all the time to respond and provide necessary help. I will try to provide more details on the use cases for our workflow next time onwards.

I will not answer you anymore, since this would get unpolite.

Sorry to say but any 3rd person reading this thread would feel that your answers were unpolite already.
I got your point and understand when one supports opensource product and questions coming from all around the world with different understanding and expectations. So I don’t mind that.
I tried to give as much information as necessary in my question, but my question was specific to one point and you tried to answer everything except that one point. Again, let me be clear, I am not complaining on that. The information you provided was very much necessary for me to get overall context on what privacyidea does support. I don’t have complete picture of how this tool works but you do.
So at some places, I may have assumed certain things (but not necessarily those are the only use cases that privacyidea supports), so I might have missed a few and I do acknowledge that miss on my part too.
I will keep posting new threads with relevant use cases and problem information, if any.
Thanks for all the help!

What point was not answered?

GET /token/ will not return user information.

If you need user information you need to do GET /user/.

This was the question (related to usage of “user_fields” parameter in /token endpoint).
I found “user_fields” in https://buildmedia.readthedocs.org/media/pdf/privacyidea/latest/privacyidea.pdf (If I search for user_fields there’s only one place in this document)
As per documentation user_fields corresponds to : additional user fields from the userid resolver of the owner (user)

So here’s my understanding from this documentation statement:
From my user id resolver (http resolver in my case), I can set some additional fields to a user and query a token using /token endpoint with “user_fields” parameter. My understanding maybe wrong, but that’s what I am trying to find out.

At present, when I call /token endpoint with ANY value for user_fields parameter, it gives me the same result. When I don’t pass this field “user_fields”, still I get the same results back.
So what value is expected here for “user_fields” parameter and what does it correspond to and how can those be set?

I hope the question is now clear.
Appreciate your help!