Notes from the field: Configuring Atlassian Access with Workspace ONE Access

Atlassian Access is the SSO portal being used for SSO access across Jira, Confluence etc. for the configuration part see the following url: https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information according to above article:

  • Single Sign On URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Recipient URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Application ID https://auth.atlassian.com/saml/”uniqesamlidprovided
  • Username Format = Unspecified
  • Username Value = ${user.email}
  • Relay State URL = https://id.atlassian.com/login

Add the custom attribute mappings for firstname, lastname and userprincipalname.

Notes from the field: UEM/vIDM integration caveats

Not too long ago I encountered some issues when configuring UEM and IDM integration. When providing the vIDM URL in UEM for configuring the integration it would error out with below error:

After some troubleshooting it appeared that the access policies where not properly configured as in the last rule in the default access application ruleset was blocking access. Resolution was editing the default policy and ending it with the password method which is associated with the built-in workspace IDP, after that the integration part is working as expected.

Another configuration task which caught me by surprise was that after the configuration is set up between UEM and vIDM the following errors occurred:

Turned out that the integration between UEM and vIDM is depending on Active Directory integration. The basic system domain accounts (even full admins) won’t work in this scenario. Resolution is configuring an domain account with the necessary admin rights in both tenants and then it will work as expected.

Hope this helps!

Notes from the field: vIDM and o365 modern authentication delay

Just a quick win blog to mention and give a heads-up that when you are in the process of configuring vIDM and o365 you might encounter native clients prompting for authentication and a big ass delay when you flip over the authentication and the requested domain from managed to federated with vIDM. This might be up to eight hours!!! Thanks to the #community #vExpert that I got this answer quite fast because I recalled that Laurens van Duijn put something similar in the vExpert Slack group mentioning that he saw this kind of behavior.

So in summary, do it on a Friday and inform your users.

Big shout out to Laurens van Duijn and be sure to follow him on twitter and his blog

Twitter: @LaurensvanDuijn

Blog: https://vdr.one/