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

Org admins must be able to enforce a particular social login as the log in method

    • 221
    • Hide

      Updated December 23, 2024

      Thank you for all of your feedback on this issue. I can now confirm that a solution is In Progress for hiding the social options on the login screen. We understand the importance of this issue, and we are targeting to deliver it to you as quickly as possible. Please stay tuned for updates on timing.

      Please also take this survey regarding additional login page customizations: https://surveys.atlassian.com/jfe/form/SV_23rLM3qYWqbGeUe 

      We look forward to your feedback!

      Thank you!

      Show
      Updated December 23, 2024 Thank you for all of your feedback on this issue. I can now confirm that a solution is In Progress for hiding the social options on the login screen. We understand the importance of this issue, and we are targeting to deliver it to you as quickly as possible. Please stay tuned for updates on timing. Please also take this survey regarding additional login page customizations: https://surveys.atlassian.com/jfe/form/SV_23rLM3qYWqbGeUe   We look forward to your feedback! Thank you!
    • 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.

      Problem

      If you enforce SSO to your users through Azure, for example, and they use the social login "Continue with Microsoft", they will not log in with SAML, instead, they will use a specific flow.

      As a result, a new app will be created at your Azure enterprise apps, called "Atlassian", and the user will be assigned to that app.

      Suggestion

      Integrate the social login functionality with the SAML implementation, so when the user clicks that button, the system automatically recognizes he is a SAML user.

      Workaround

      For now, users should use the email to trigger the SAML authentication flow

        1. connectionMicrosoft.png
          connectionMicrosoft.png
          23 kB
        2. Login error.jpg
          Login error.jpg
          43 kB

            [ACCESS-894] Org admins must be able to enforce a particular social login as the log in method

            We have actively started investigating this feature and will provide more updates as we have them.

            Holly Makris (Inactive) added a comment - We have actively started investigating this feature and will provide more updates as we have them.

            Any update on whether this will be implemented?

            Robert.Ogden added a comment - Any update on whether this will be implemented?

            Adrian Bole added a comment - - edited

            We would also like this to be implemented. It adds variability to the login process which needs to be very secure (especially in this day and age). 

            Adrian Bole added a comment - - edited We would also like this to be implemented. It adds variability to the login process which needs to be very secure (especially in this day and age). 

            same.  need to force SSO only.  Or need to be able to control which login methods are available to the domain.

            Like maybe the ability to have

            SSO + Google + Microsoft = ok, but disable Apple and Slack.

            Or just SSO and no social.

            Jeff Little added a comment - same.  need to force SSO only.  Or need to be able to control which login methods are available to the domain. Like maybe the ability to have SSO + Google + Microsoft = ok, but disable Apple and Slack. Or just SSO and no social.

            Peter Black added a comment - - edited

            This is not a major issue, but it is annoying. We regularly have new staff selecting "continue with Microsoft" and we have to provide specific guidance on what they need to do. An option to remove the social buttons would be reasonable. I should also note that I raised a support request and had a pleasant call with the support team where they found this issue for me, so there are non-negligible support costs arising from this usability issue.

            Peter Black added a comment - - edited This is not a major issue, but it is annoying. We regularly have new staff selecting "continue with Microsoft" and we have to provide specific guidance on what they need to do. An option to remove the social buttons would be reasonable. I should also note that I raised a support request and had a pleasant call with the support team where they found this issue for me, so there are non-negligible support costs arising from this usability issue.

            david.harper1982555711, that is correct, at the moment it is not possible to remove/edit the social login buttons. We are tracking this as a feature request at https://jira.atlassian.com/browse/ID-6647.

            Gabriel Muller (Inactive) added a comment - david.harper1982555711 , that is correct, at the moment it is not possible to remove/edit the social login buttons. We are tracking this as a feature request at https://jira.atlassian.com/browse/ID-6647 .

            Yes. Same here as nicolas.gavard. There has been some confusion around clicking the Microsoft button and then not being allowed access.

            I take it there is no way of removing the social login buttons?

            David Harper added a comment - Yes. Same here as nicolas.gavard. There has been some confusion around clicking the Microsoft button and then not being allowed access. I take it there is no way of removing the social login buttons?

            In our case, we setup SAML with AzureAD as IDP.

            If the user fill his email adress in the login form, the SSO process work as expected.

            But if the user choose "continue with Microsoft", the process fails because id.Atlassian.com is not authorized to get resources from microsoft.

            Users are confused why this 2nd use case is not working (they know that authentication system are managed by microsoft)

            nicolas.gavard added a comment - In our case, we setup SAML with AzureAD as IDP. If the user fill his email adress in the login form, the SSO process work as expected. But if the user choose "continue with Microsoft", the process fails because id.Atlassian.com is not authorized to get resources from microsoft. Users are confused why this 2nd use case is not working (they know that authentication system are managed by microsoft)

              cc2e0558d9b4 Ruchi Rai
              gmuller Gabriel Muller (Inactive)
              Votes:
              107 Vote for this issue
              Watchers:
              98 Start watching this issue

                Created:
                Updated: