Failure to ass Assigning an RSA Token

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.4
people can help. If you do not know, put Unsure.]*

Please share any images or screenshots, if relevant.

Attempt to provision an RSA Token is failing with the following error "
error message “Failed to get Token: Required data is missing from command com.rsa.command.exception.InvalidArgumentException: Required data is missing from command”

the xml is below:








2 
<ProvisioningPlan>
  <AccountRequest application="RSA" nativeIdentity="ims.c0c6733996424c8473eaffff25b43cf3" op="Modify">
    <AttributeRequest name="notes" op="Set" value="Manually Updated by IIQ per order:4800322"/>
    <AttributeRequest name="firstName" op="Set" value="Noam"/>
    <AttributeRequest name="lastName" op="Set" value="Shemesh"/>
    <AttributeRequest name="accountExpireDate" op="Set" value="Jan 01, 2027 11:59:00 PM GMT+0200"/>
    <AttributeRequest name="tokens" op="Add" value=""/>
  </AccountRequest>
</ProvisioningPlan>
3

Hi @AviWIS - Are you adding a specific token or wanting the system to assign the next available?

4

Hi Ryan.
Thank you for the prompt response.
Initially we tried to use “next available”, but the problem is that a KYFOBO or a SOFTID token is selected randomly.
We need either to select the next available SOFT TOKEN (SOFTID), or, alternatively we can select a specific Token (we know its guid and serial number).

What would be the “best practice” solution for our case?

thank you,
Avi.

5

please note below the code I am trying to use:```

```
6
7

ttributeRequest name=“tokens” op=“Add” value=“000123123123”

8

@AviWIS ,

In most RSA + SailPoint implementations, “best practice” for assigning a particular type of token (e.g. soft vs. hardware) is to either:

  1. Use a dedicated pool or policy in RSA that contains only the kind of token you want to assign (“soft token pool”), and continue to use “next available.” This way, you still rely on “auto-assignment,” but you limit that assignment to a particular token pool so that you do not accidentally get a hardware token.

  2. Specify the exact token serial number or GUID (if you need a particular token). In that case, your provisioning plan or provisioning policy needs to set the tokens attribute to the serial number or GUID of the soft token you want to assign.

Why “Next Available” Sometimes Fails

By default, RSA will look at all pools to pick the “next available” token; if you have multiple token types (hard vs. soft) in the general pool, RSA can select either one at random. Hence why you’ve seen your assignment come back with a hardware token sometimes.

Recommended Approach

The usual best practice (and simplest to maintain going forward) is:

  1. Create a separate (soft-token-only) pool or provisioning rule in RSA.
  2. In IdentityIQ, update your RSA Application configuration (or your Provisioning Policy) to point to that soft token pool only.
  3. Continue to use “next available” in the provisioning plan.

This ensures that the user always gets a soft token when you do an Add/Set on the tokens attribute without having to hardcode a serial or GUID.

If You Need a Specific Token

If you must assign a specific token you already know about (for example, one that was pre-generated, or one that you must reassign), you can simply pass its serial number or token GUID in the tokens attribute. For example:

<AttributeRequest name="tokens" op="Add" value="<InsertSerialNumberOrGuidHere>" />

This will instruct RSA to assign that exact token to the user.

Example Provisioning Plan Snippet

Assuming you have a dedicated pool for soft tokens, your plan might look like:

<ProvisioningPlan>
    <AccountRequest application="RSA" nativeIdentity="ims.c0c6733996424c8473eaffff25b43cf3" op="Modify">
        <AttributeRequest name="notes" op="Set" value="Manually Updated by IIQ per order:4800322"/>
        <AttributeRequest name="firstName" op="Set" value="Noam"/>
        <AttributeRequest name="lastName" op="Set" value="Shemesh"/>
        <AttributeRequest name="accountExpireDate" op="Set" value="Jan 01, 2027 11:59:00 PM GMT+0200"/>
        <!-- "tokens" op="Add" without value, or with a placeholder, 
             as long as your RSA application knows to pick from the 
             soft-token-only pool. -->
        <AttributeRequest name="tokens" op="Add" value="" />
    </AccountRequest>
</ProvisioningPlan>

Of course, the exact configuration may differ slightly depending on how your RSA connector is set up in IdentityIQ, but the principle remains: let RSA “auto-assign” from the correct pool (soft tokens) or specify the exact token if needed.

Bottom Line

  • If you want a random soft token: Create or configure a separate pool/policy in RSA for only soft tokens, and use “next available.”
  • If you want a specific known token: Supply its serial number or GUID in the provisioning plan.

This is generally the cleanest, most sustainable way to manage token assignments within RSA and SailPoint IdentityIQ.

Hope this helps.

1 Like
9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.