SAM - Subscription Assigned Field is empty

[Dattatraygh]

Hello experts,

Please go through the problem mentioned below and suggest me the best resolution.

Out of 565 subscriptions, only 17 subscriptions are directly assigned(created through SSO Application Users). Remaining(548) are given through 2 different SSO Application Groups.

Now the problem is, for these 17 subscriptions, "Subscription Assigned" field is showing some value but for remaining subscription(which are created through SSO Application Groups), the same field is empty.

I have gone through the documents and found that this is the OOTB behaviour. And thats the end of the research.

But still, I believe, there might be some way to get these details from okta. And that is why I came here to share this problem with you.

Please help me out with this. Any single clue will be helpful. Current job might be pulling the "subscription assigned" field value, for direct users only, using the API. You can suggest me the other APIs which can be used to pull this "subscription assigned" field value for all the subscriptions which are assigned through group also.

[Vikram Reddy]

Hi @Dattatraygh,

This is a known gap, not a bug you introduced. Okta's Application Users API (GET /api/v1/apps/{appId}/users) returns a scope value on every AppUser record: USER for someone assigned straight to the app, GROUP for someone who got in through an app group push. Most homegrown or OOTB SAM Pro SSO pulls only pick up the USER-scope records for the Subscription Assigned field, because that's the clean one-to-one mapping. Group-scope entries come back on that same call but usually get ignored or only logged at the group level, which is exactly your 548 blanks.

Before writing new code, check these:

• Existing job: find whatever hits the Okta Apps API today and confirm it filters on scope=USER only.
• samp_sw_subscription: check whether the group-provisioned rows even land in this table with a blank Assigned field, or don't land at all.
• Group membership API: GET /api/v1/groups/{groupId}/users against your 2 SSO Application Groups gives you the actual member list, which you can join back to the subscription record by user.
• Subscription Condition on the Software Model (San Diego and later): won't fill this field, but it lets you scope a model to a group so your compliance counts stay right in the meantime.

Share which integration profile or transform map runs that job and I can point at the exact spot to patch.

Thank you,
Vikram Karety
Octigo Solutions INC

[Dattatraygh]

Hello @Vikram Reddy 

Thanks for sharing the knowlede.

It is using Okta Sam Integration profile to run "Download applications" and "Update connected applications" jobs. There are other jobs alos whihc are downloading the Directory Groups and Directory users which are using the same integration profile.

That is the only thing I can confirm.

[Vikram Reddy]

Hey @Dattatraygh,

Since all 548 empty rows trace back to the two SSO Application Groups, this isn't an integration profile or job problem, the same Okta SAM Integration profile is clearly working fine for Directory Groups and Directory Users. The Subscription Assigned field is written at the individual-assignment level, and group-based access was never designed to populate it through the Update connected applications job. The actual fix for this scenario is the SSO group software model mapping: map each of those two SSO groups to its software model directly, and group members get counted against the entitlement without needing a per-user Subscription Assigned value. Set that up instead of digging further into the job logic.

Thank you,
Vikram Karety
Octigo Solutions INC