Hi everyone. I'm setting up Secureframe for our team and hit a snag with SSO sync.
Our identity provider is Okta. The connection test passes, and about half our team appears in the training module automatically. But the other half is just... missing. No errors in the logs I can see.
Has anyone else run into this? I'm wondering if it's a group assignment issue in Okta or maybe a attribute mapping problem. What specific user attributes does Secureframe look for to provision a user into the training module?
If it helps, our Okta app user profile looks like this:
```yaml
appuser:
email: user.email
firstName: user.firstName
lastName: user.lastName
department: user.department
```
Is there a required field I'm missing?
Containers are magic, but I want to know how the magic works.
That's a tricky one, especially with the connection test passing. The attribute mapping in your Okta profile looks correct for the basics.
It could be a group assignment or scope issue in Okta. Are the missing users in the correct Okta group that's assigned to the Secureframe app? Sometimes provisioning is configured to only sync users from specific groups.
A follow-up from my own setup: Secureframe's support told me they also look for a valid `employeeNumber` or `username` attribute for reliable matching, though it's not always listed as mandatory. You might check if that field is populated consistently for the missing half of your team.
Thanks for posting this - I'm setting up a similar integration next month and this is really helpful to watch.
Yeah, the silent failure on the missing users is the real headache. A passing connection test only confirms the handshake, not the actual user provisioning logic.
You've got the basic attribute mapping covered. The culprit is almost always one of two things in Okta: either the group assignment rule for the Secureframe app, or a scope filter that's inadvertently excluding people based on a department or location attribute.
I'd start by pulling the provisioning logs for a single missing user from the Okta admin console, not Secureframe's logs. Look for a line that says something like "Skipping user because of group membership" or "User not in scope." That'll point you right at the rule that's filtering them out.
api first
That attribute mapping is incomplete. Secureframe's SCIM provisioning needs a stable, unique identifier that isn't email. Email can change and that breaks the user record link.
You're missing the `userName` attribute mapping. It's mandatory for their system to correctly match and provision users, even if the docs downplay it. The half that's missing probably have a null or mismatched `userName` field in Okta compared to what Secureframe expects. Your Okta app profile should look like this:
```yaml
appuser:
userName: user.login # or user.email, but be consistent across all users
email: user.email
firstName: user.firstName
lastName: user.lastName
```
Check the `user.login` value in Okta for one of the missing users versus one who synced correctly. I've seen this cause exactly the silent failure you're describing.