Hi,

We are excited to announce that we have shipped the Authentication policies feature. Using this feature you can test SSO on a few accounts before enabling it across your organization (https://www.atlassian.com/software/access/guide/elements/authentication-policies#why-apply-multiple-authentication-policies). We are still in the last leg of the rollout. If your organization doesn’t have the feature yet, file a support ticket (https://support.atlassian.com/contact/#/) and we will enable the feature for you.

Thanks,

The Atlassian Access team.

In general, the ability to have the SSO settings configured and stored, but not enabled globally (ie the ability to toggle on/off) is both expected "minimum viable product", but also critical to operational practices.  In addition, this could be implemented in a fashion piggybacking on ACCESS-85, where conversely to disabling SSO for administrative users, it could be enabled in limited scope to support testing and a path to application globally.

Hi spencescu,

Unfortunately we don't have a timeline right now on when we will provide any sandbox capabilities for SAML; our current recommended approach is to test the configuration on a subdomain, like text.yourdomain.com, prior to verifying your production domain.

Regards,
Dave Meyer
Atlassian Access Product Management

Is there any ETA for some progress here?

Some apps have a "SAML test" button in order to verify the config. It seems the Atlassian SAML config (and the Google authentication too for that matter) require DNS changes which need time to propagate - which means downtime beyond an organization's control. 

I have configured SAML for many apps and it is not a great ordeal, so I suggest to simplify the process.

I would add also that being able to schedule the outage and have a named Atlassian support rep with SAML configuration knowledge on hand to call immediately to resolve issues would be helpful. Having to submit a ticket and using one time links to access if it goes wrong doesn't speak to a supportive process from the vendor

One possible implementation would be providing the ability to enable SSO for the org, and only apply it "per site" so admins could test on a non-production site.

It would be very helpful to have a chart that shows the provisioning aspects of all SSO solutions next to each other (ex: provisioning details, user creation, disabled users, deleted users, sync speed, etc).