Gettign Error: blockedByReason=Blocked%20by%20SCIM&blockedBy

[Arpit Gupta]

Setup SAML SSO login from IDP to Atlassian from teo domain directory from IDP.

But when login from the user giving error: https://id.atlassian.com/login/inactive?blockedByReason=Blocked%20by%20SCIM&blockedByType=orgAdmin

[Arkadiusz Wroblewski]

Hello @ Arpit Gupta 

this error points to SCIM provisioning, not to SAML itself.

blockedByReason=Blocked by SCIM means the user is still being controlled by the IdP sync, so I would check the user there first:

- confirm the account is still active
- confirm the user is still assigned to the Atlassian app / provisioning scope
- then let SCIM sync again

I would also check the Atlassian Admin audit log to see whether the user was deactivated or removed by provisioning.

The key point is:
if the account is still SCIM-managed, the fix usually has to happen in the IdP, not in Jira.

If the user is no longer SCIM-managed, then you can handle it in Managed accounts in Atlassian Admin.

[Arpit Gupta]

My initial configuration involved a Google IDP SAML application (Search by App >> Atlassian Web (SAML)) with auto-provisioning enabled, targeting a specific Google Group. On the Atlassian side, a corresponding group was set up, and users were synced from the IDP. I had also configured the Atlassian identity provider with two verified domains, which claimed all users from my Google IDP.

I ultimately deleted this entire configuration because it seemed flawed and not a true representation of SAML user provisioning & JIT.

Goal: Implement Just-In-Time (JIT) user provisioning from Google IDP (Add custom SAML app) to Atlassian.

Steps Taken (Reconfiguration):

Removed all prior SAML application configurations from both Google IDP and the Atlassian IDP setup.

Activated all deactivated accounts within the Atlassian managed domain.

Unclaimed all accounts from the domain.

Created a new SAML application in Google IDP and set its status to ON for a specific Google Group.

Recreated the IDP in Atlassian, linking it to the two verified domains.

   - Auto-provisioning is currently disabled.

   - Defined an authentication policy with SAML SSO enabled.

Configured the App Access setting to allow users from these two domains access to the app, specifying that admin approval is needed (as a user).

Current Issue:

 When logging in via an incognito window using a profile (xyz.verifieddomain.com) and accessing a Jira ticket, the ticket opens successfully, but the user is classified as an external user in Atlassian.

Question: Why is the new authentication policy not recognizing this user?

Help me setup JIT from my google workspace domain to atlasian Jira

[Arkadiusz Wroblewski]

@ Arpit Gupta 

that extra detail actually explains the behavior quite well.

Right now you have two different mechanisms in play at the same time: SAML login and app access onboarding with admin approval. Those are not the same thing as JIT provisioning into managed accounts, and they don’t behave the same way.

The key point is how Atlassian treats the domain. By unclaiming the domain and users, you removed the foundation that JIT relies on. In Atlassian Cloud, JIT provisioning is tied to a claimed and linked domain, where the identity provider is trusted to create and manage users. Without that, Atlassian will not turn a login into a managed account automatically.

So what happens in your setup is consistent:

The user signs in via SAML, but because the domain is not claimed, Atlassian does not treat them as a managed-domain user. At the same time, your app access setting with admin approval allows them to request or receive access to the product. That path gives them access, but it does not convert them into a managed account. That is why they show up as an external user.

So this is not the authentication policy failing. It is the system behaving according to the current setup.

If your goal is true JIT provisioning from Google Workspace, then I would simplify the model and align it with how Atlassian expects it to work:

- Make sure the domain is verified and claimed automatically, link that domain to your identity provider, and enforce SSO on the default authentication policy. That way, when a user signs in via SAML, Atlassian can create and manage the account as part of that flow.

- If you keep the domain unclaimed and rely on app access approvals, you are effectively choosing a different onboarding model. It works, but it will always result in users being treated as external rather than managed.

So the decision point here is really about intent:

- If you want centralized identity control and JIT → go with claimed domain + SSO + IdP linkage
- If you want more open access with approvals → app access settings will work, but users will not become managed accounts

[Arpit Gupta]

- Make sure the domain is verified and claimed automatically, link that domain to your identity provider, and enforce SSO on the default authentication policy. That way, when a user signs in via SAML, Atlassian can create and manage the account as part of that flow.
    - This setup i have created. Just to confirm I did not choose default policy but I created new authentication policy under the IDP i created & enabled SSO & Auto Provisioning. Is that ok?

Secondly, The reason behind choosing 'app access settings' because there is a case when the sync of the user from google IDP towards Atlassian is pending & at the same time that user try to SSO then it throws error 'Permission Denied'. This was the gap & bottle neck. [Can you suggest me something to fill this gap?]