Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-2122

Notification Service for User Provisioning in Osync Setup (Azure AD with Nested Groups)

XMLWordPrintable

    • 4

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Description:

      At present, admins do not receive email notifications when provisioning sync encounters failures or any errors occur.

      Suggestion:

      It would be beneficial for admins to receive alerts specifically for any sync failures related to the Osync setup. This is because Azure Osync depends on a Graph Token, which is automatically generated by the application in Azure during the Osync setup. If this token becomes invalid or is lost, the sync process halts and will not resume until the issue is addressed.

      Receiving notifications would allow admins to promptly address the issue without having to manually check the configuration in the UI to determine if user syncs are failing. This would enable them to quickly resolve the problem and continue the sync process.

            [ACCESS-2122] Notification Service for User Provisioning in Osync Setup (Azure AD with Nested Groups)

            John Eisenschmidt (External) added a comment - - edited

            One of my clients implemented JSM/Jira/Confluence Cloud last year, including EntraID/AD integration with Guard/Access last spring. We determined this past January that a number of problems they were having were related to this issue: Users were able to SSO login using their Microsoft accounts for months while Groups were not syncing between Entra and Guard, causing automatic provisioning and role-based authorization to be incorrect. This is a bizarre failure state for a paid product that integrates with one's IdP: AuthN works, AuthZ silently doesn't. 

            This could be resolved either by (ideally) eliminating the need for that OAuth step as part of SAML integration (most systems, including Atlassian Crowd IIRC, use one of the other – not both) or minimally when that big pink box appears on the Identity Provider screen in Guard to indicate it hasn't synced, it should send an email notification to the Org Administrators - every time the sync fails. 

             

            Related: [PCS-370005]

            John Eisenschmidt (External) added a comment - - edited One of my clients implemented JSM/Jira/Confluence Cloud last year, including EntraID/AD integration with Guard/Access last spring. We determined this past January that a number of problems they were having were related to this issue: Users were able to SSO login using their Microsoft accounts for months while Groups were not syncing between Entra and Guard, causing automatic provisioning and role-based authorization to be incorrect. This is a bizarre failure state for a paid product that integrates with one's IdP: AuthN works, AuthZ silently doesn't.  This could be resolved either by (ideally) eliminating the need for that OAuth step as part of SAML integration (most systems, including Atlassian Crowd IIRC, use one of the other – not both) or minimally when that big pink box appears on the Identity Provider screen in Guard to indicate it hasn't synced, it should send an email notification to the Org Administrators - every time the sync fails.    Related: [PCS-370005]

              Unassigned Unassigned
              6af61acd71eb Praneeth Garimella
              Votes:
              4 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: