What is the best practice setting up one Okta Tile for Atlassian Cloud that points to "home.atlassian.com", where the user can see the Atlassian apps that they have access to. We will be using SSO/SCIM and pushing the groups from Okta.
@Michael Bibby ,
Two separate things are tangled in "one tile", and splitting them is the whole answer.
1. The SSO and SCIM app is not your tile; it is your plumbing. Set up the Okta Atlassian Cloud application the way Atlassian's Okta SAML guide describes: verified domain, Atlassian Guard Standard, the SAML wizard under Atlassian Administration, Security, Identity providers, Okta, then SCIM with group push from the same app. That app supports both SP-initiated and IdP-initiated SSO (the guide lists both), so users can start from Okta or from any Atlassian URL. Its Sign On tab has separate base URL fields for Jira, Confluence and Statuspage; each one you fill produces its own app link on the user's Okta dashboard. That is the source of the "many tiles" problem, and it is also why leaving those product URLs empty is a reasonable choice if you want a single front door. I have not confirmed on a live tenant what the Atlassian Cloud app's own tile does when all three base URLs are blank, so test that on one pilot user before you decide.
2. The single front door is a plain Okta Bookmark app pointing at https://home.atlassian.com. Atlassian Home is the one page that shows a user every Atlassian app they have access to, which is exactly what you asked for. Because SAML SSO is already enforced for your verified domain, a user clicking the bookmark hits home.atlassian.com, enters their email (or is remembered), is redirected to Okta where they already have a session, and lands back on Home signed in. That is an SP-initiated flow and it works with no RelayState configuration at all. Assign the bookmark to the same Okta groups you push via SCIM so the tile and the access always agree.
https://home.atlassian.com
Why not point the SAML app's Default RelayState at Home instead? You can try it, and IdP-initiated SSO is supported, but the bookmark approach has two advantages in practice: it survives any change Atlassian makes to how IdP-initiated sessions land, and it keeps the SAML app's configuration minimal, which is what you want when you are also running SCIM through it.
Checklist
Verified against the Okta SAML guide on 7 October 2026; the bookmark pattern is standard Okta practice, not an Atlassian-documented step, so it is stated as such.
@Sami Shaik nailed it on the head.
To sum it up - the Okta Tile is just the tunnel.
The real meat and potatoes is you have an Okta Group (Key word - "Push Group") that is pushed to your Atlassian Org that would auto grant an App (Jira for example) - once you get that far - including all the fine print Sami pointed out - you would have essentially what you are looking for.
If you don't assign an app - they will get a "You do not have access to this" which results in them requesting access - which is unnecessary added labor - hence my suggested App assignment.
Also note - Okta isn't the one granting the App - its just Authentication/provisioning the account.
You will need to id the Okta pushed group and assign the app role appropriate in the Org Admin/Directory/Site Controls.
Be warned - watch your seat counts. You could run out before you realize it if you get carried away.
Regularly audit your accounts.
If it was me? And I had "Service Collection"? - I'd auto grant Jira Service management "Customer" to all accounts - and push them to the Portal to request further access as they may need something different. As customer is free/non-billable.
But that depends on your Org/Apps/various factors.
PS: You will need Atlassian Guard's Standard or an Enterprise Plan to even sneeze at Okta.
PS2: We use Okta - so very familiar with its pros and cons. 😁
@Sami Shaik FYI we tried leaving the URL's blank, and we received a configuration error when we tried to login thru Okta. We are continuing to research to see if this is possible, and will post our findings.
Thanks for testing it, and I owe you a correction. I flagged the blank-URL idea as unconfirmed, and your result settles it: do not leave the base URL fields blank. Atlassian’s own Okta setup guide (step 7) fills all three: Jira Base URL https://yoursite.atlassian.net, Confluence Base URL the same with /wiki, Statuspage Base URL https://manage.statuspage.io. Put them back exactly like that and the configuration error should clear.
https://yoursite.atlassian.net
/wiki
https://manage.statuspage.io
The single front door then comes from Okta, not from the Atlassian app:
Test with one user who has a single product before rolling it out. If the bookmark lands anywhere other than Home for that user, post what you see and I will look again.
It looks like you're new here. Sign in or register to get started.
