I have created a workaround - For JSM

• Turned off Customer Notification schema

• Created my own automation with e-mail and included the following link:

https://id.atlassian.com/login?email=EMAIL&application=jira&continue=https%3A%2F%2FSUBDOMAIN.atlassian.net%2Fservicedesk%2Fcustomer%2Fportal%2F8%2FJSMPROJECTKEY-ISSUEKEY

EMAIL: Always customer

SUBDOMAIN: Your client (subdomain.atlassian.net)

PROJECTKEY-Issuekey: XYZ-123

Only tested with SSO + M365

Anyone who now logs on to the link in Outlook will be forwarded/redirected to log on accordingly. If your e-mail is not in the link because you were not the recipient, then you log in with your logged-in user from the Outlook session.

Now Atlassian:

Tell me why, you guys don't already do this under the subdomain always/automatically?

Whether there is already an SSO/M365 session!

• My IT security had no concerns
• For our spam filter to be on the safe side: Enter the URL in the whitelist (https://id.atlassian.com/login?email=*)

EDIT:

workaround only works automatically if the customer is not logged in. The second time you call it up, you have to log in once with a pre-filled recipient address.

Edit #2

URL With Smart Value

https://id.atlassian.com/login?email=\issue.reporter.emailAddress&application=jira&continue=https://SUBDOMAIN.atlassian.net/servicedesk/customer/portal/8/{

}

Not just the need to log in. How about following a link (in an email or chat message) and getting a browser page with "this page doesn't exist" or a "you don't have permission to see this page"?

Which message you get depends on whether the sender copied it out of the URL bar or got it from the "share" (and there is a third one I can't recall ATM). If a user doesn't have permission because they aren't logged in, at least offer the link right there and suggest that they log in first! If the user is savvy enough to click the non-obvious login icon and enter their email address (three times!), they usually are not sent back to the original page they wanted to see. They have to go back and re-click the email/chat link!

Wiki use has dropped precipitously since we moved off-prem to the cloud because folks just give up for any one of the obstacles put in the way.

What is the latest ETA for this enhancement?

The requirement to log in every day (even with using SSO) is the number one complaint at my company, so anything will help.

Thank you all for your continued comments on this feature request. It will remain open after the launch of "Remember me" and we will continue to explore how we can address your feedback.

As a reminder, the Identity team will be adding a “remember” option to the log in screen that will allow users to avoid having to re-enter their email in future visits.

The Identity team is working to get this feature out as soon as possible, we will post here as soon as the "Remember me" option is available. 

I'm afraid I'm going to have to pile on here and say that, while I understand the challenges when it comes to SP-initiated logins and SAML, the implementation here is sub-par compared to other SaaS software. Absent any other info, asking for an email address is common practice for these kinds of SAML implementations, as the SP doesn't actually know where to send the authentication request to unless it can map the user to a tenant. However, if our users are clicking an Atlassian site link for https://myorg.atlassian.net, which should be globally unique, the SP should be receiving a referral with that information and redirecting automatically to the configured IdP for the myorg tenant.

I think implementation of a "Remember" button should be seen as nothing more than a stop gap while a permanent solution is implemented. This proposed solution isn't addressing the desired functionality and, depending on how it's implemented, can be hindered by other org policies on user endpoints.

Nothing I'm adding here hasn't been said on this request already, and the fact this request has been opened for over 6 years doesn't give one much hope that Atlassian understands how to resolve or has the desire to resolve. Have to say, having recently migrated from on-prem Atlassian to cloud, it's been very hard to argue to the executive team and CEO why this is a step forward.

Hi,

I understand that you will release a new "remember" option on the login page by the end of November.

However, I do not see this feature as a solution to the actual problem. The root cause is still the login page itself - it should not appear during the login process when SSO is enabled, as it is counterintuitive.

Could you provide a timeframe for a solution that eliminates the login page entirely when SSO is enabled?

Atlassian should know the IdP to forward the auth request to based on the custom subdomain.

Thank you Holly for that good news.

I see in the discussions that the topic is not clear for all:

• Atlassian has to know the email address of the user before login can happen, as they select the SSO provider (from the users company or google or microsoft) based on the domain of the email address.
  After the user has entered this, they are forwarded to SSO. On our system, user has now to enter their company userid.
  Basically, that makes sense - but when I am not logged in but I return, it would be great if the system remembers my email address, so I only have to press Enter.
• For SSO, an ORG admin can defined how long a session is valid, e.g. 12h, so on the next morning the users have to confirm their login. Here, the user is not logged out - but they still have to re-enter their email address. This is not necessary.

The complexity Atlassian has seems to me they have to set a cookie

• when I logout to remember who I was last time, so they can pre-fill the email field
• when I am logged in so they know who I am and can directly forward me to to my SSO without asking. If I want another user, I can always logout and enter a new email address.

Please do not confuse this with a new feature which is announced for Oct 2024: Atlassian enables ORG admins to define the SSO which ALL users of an ORG have to use - by this, the SSO is no longer derived from the user's email address, but it uses the SSO defined in the ORG. This makes the 2FA email sending process unnecessary - as long as all users of the ORG are known in the SSO, so you cannot invite other users any more.

Hello Holly Makris,

we need a solution for this. There are many other web applications out there without this problem when I link it to a SSO provider. The Atlassian web apps want to check first the email and then goes into the authentication process. The only thing your customers want is that you look into it and short this process like million other web applications developers does in the past. This can’t be complex. 

Best regars

Ridiculous! If a user goes to a url that starts with "https://<entity>.atlassian.net/wiki" and it is not a public URL, pass them to the <entity> SSO portal. If their credentials allow them access, they get access. If they don't, no access. Simple, NOT complex!

If it is a public URL, show them the page. If they want to edit it (or comment or anything that requires authentication), they can click the login link and be sent to the <entity> SSO portal. Also simple!

You do not need to ask for an address (or check for a "remember me" cookie) first for either situation. Any identifier you need should be negotiated and handed over by the SSO provider. ONLY if said <entity> has multiple authentication methods might you need to ask (or simply ask which authentication method they want to use – without collecting an address). Administrative accounts outside of SSO should have their own login portal site anyway.

We have received an update from the Identity team on this feature request. They will be adding a “remember” option to the log in screen that will allow users to avoid having to re-enter their email in future visits. Due to the complexities associated with this feature and allowing time for the appropriate security reviews, this feature will be delivered by the end of November.

We will provide more information as we have it, thank you for your continued feedback

HI Team Wanted to see whether we have defined go live date for this suggestion or its track for October 4  ?

https://getsupport.atlassian.com/browse/JST-1038801

That sounds great, getting that in October.

If the user does not have to enter their email address (you did not write how the new interaction will be), they should also not have to enter their email address when they have to confirm their login status after an inactivity timeout! Our users login once, then stay logged in for a long time, but have to enter their email address every morning to be forwarded to the SSO provider. If only the initial login is fixed, not many users will notice that at all.

This project is committed on the Identity-team roadmap with a delivery date of October 4, 2024.

It was created in 2018 and now it's 2024... 

Atlassian, it is time to move it to "In progress". 

This project has been committed for Q1, will move to In Progress with specific dates when I receive them.

Hi all, I have just taken over ownership of this issue and am actively working with our Identity team to prioritize the project and commit to a timeline, stay tuned for an update within the next few weeks.

Currently, out of over 550 issues, this is the 4th most up-voted feature suggestion and the 20th oldest.  Yet, it is still just "gathering interest" and does not appear to be on the roadmap.  What is the point of these feature requests if you are just going to add the things your marketing team thinks are "cool"?

I've seen so many web-savvy users struggle to log in since we migrated to the cloud. As a web designer, my job is to make the web easier for people to use, so it's very disappointing to me that our users now have a harder time getting to our Wiki.

I've studied users with cognitive disabilities and from that, I can tell you that this extra step, plus the added frustration felt by the user significantly increases the challenge of using this website. That makes users less likely to try, which means you (Atlassian) lose users. From a business standpoint alone, it's in your best interest to fix this.

Thank you.

This is a much-needed feature as the first step to the cloud login.

If the URL is <entity>.atlassian.com, then admins should have the option to have the "sign in" link send the user directly to the registered IdP because the admins know that no outside users will need to authenticate.  Asking for the email address is only necessary if multiple identity providers are a possibility for the entity's site.  Currently, it's like going to a single-barber barbershop, and every single customer is asked which barber they want to have cut their hair – ridiculous! 

I agree that this negatively impacts the employee experience. We need this feature to ensure our team members continue using Atlassian products.

Highly needed because in some cases our users are putting in the wrong entry and causing login issues or duplicate users to be created for one person. 

For AzureAD there is a workaround using the "user access URL" from the enterprise application (https://launcher.myapps.microsoft.com/api/signin/xxx)
This link brings you direct to the "Atlassian Startpage"

Needed feature to optimize authentication. This is a step backward compared to what we had previously 

needed feature to optimize authentication !

I support this request and shouldn't have gone a step backward in terms of authentication.

The links provided to Atlassian tickets do not work, do we need special access to see them?
That makes it hard to understand the limitations.

OpenId Connect standard doesn't seem to be very helpful: the only hints it supports are login_hint or id_token_hint, which the client doesn't know without context.

For a company setup, the client should know which identity provider it expects.
That could also be configured in the client profile of the application on id.atlassian.com, so that doesn't require any change in client code.
Even better, we could configure hints for the federated identity provider. Example: in the case of Microsoft, it could use domain_hint=mycompany.com. This way, Microsoft won't ask to choose between personal and professional accounts.
That would achieve an end-to-end Single Sign On experience.

nb: sorry for the dummy comments below, adding a comment on that page triggers an error but actually works.

attempt to remove duplicated comment

attempt to remove duplicated comment

attempt to remove duplicated comment

attempt to remove duplicated comment

I also want to support this request:

• I understand the initial login needs an email address to decide how to ask user for login credentials, and maybe forward to their company's SSO
• An automated logout after idle time should not ask for an email again, as "the user" did not logout - in this situation the email used for the session is clear and user should be directed to the SSO page of their company immediately. There, they might have logged in before so no additional activity is necessary.

For us, this goes together with the missing "global logout" feature: If users logout at SSO, they are still logged in at Atlassian, as Atlassian does not support a callback from SSO to Access to terminate the user's session, e.g. if our company locks a userid. This might be another feature request, but I mention this here as we have to set a short idle duration to re-check if user is still allowed, which means they have to enter their email addresses very often for re-login.

I also raised CES-21698 to verify if there is not yet another solution but I heard I shoud give mit +1 to this request.

Dear Atlassian team, 

thanks for this. 

We are having an acceptance problem from our users as they need to type in the email address every time they log in to the tool. That, together with the fact it is only on the 3rd screen that they can submit a ticket, are giving us some frustrating feedback.

To my eyes, this is quite urgent.

Thanks for your great work and tool.

Best regards,

Gonçalo (raised service call PCS-212839 SSO Authentication to Jira)

Hi:

We engaged with Atlassian and they advised they do not provide a way to automatically authenticate a user if they land on a specific page. As a result, the behaviour IR are experiencing is expected.

We have the option to have a work around that will reduce the authentication login requirements. This is to increase the 'idle session duration' from current 8 hours to 24 hours.  This will mean, providing you do access Atlassian / Jira within a 24 hours period, you will only need to authenticate for the first time in the week. 

This change has been implemented.

No other actions are planned 

As others have said, this is a step backwards from how we have accessed Atlassian products in the past. 

+1

+1 company that needs this feature. All clients are in the modern cloud world now, but its not possible to SSO/SAML authenticate to Atlassian SaaS products. All users must authenticate "twice" when they get a new machine.

We are also looking for this feature. +1

thanks for the notes

We certainly have this in our action plans and our Technical Specialist Anil Jha will be commencing this very soon to understand why we haven't and resolve. I intend this to be progressed by end May

Agree, It will be best if there's option to skip id.atlassian.com and have seamless SSO experience

The lack of this capability negatively impacts the experience of our customers. It’s a step back in how our customers had previously leveraged the Atlassian products when we were running the data center versions within our environments. Our customers were used to the fact that it auto-logged them in when accessing a specific product. As more customers migrate to SAAS, this is yet another example of a feature missing or not being on par with what we had previously.

Greetings:

I have used in the past the SSO application from Resolution in Germany on Jira and Confluence and it was flawless in terms of user experience. Having SSO working as is now, is not the desired way customers expect this to work. FYI: https://support.atlassian.com/requests/PCS-157581

Please don't wait that much and don't let be biased by the few votes this ticket has received.

Best regards

Claudio

Please implement seamless SSO.  We are converting from Server to Cloud and the UX is not going to be great when we tell people they have to enter their email address twice every time.

any progress on ability to have seemless SSO. 

Continues to be a major frustration for all our users

Please implement seamless SSO

Please implement seamless SSO

Please implement seamless SSO

Please implement, SSO is supposed to be a seamless experience, having to input details each time a user logs in is counter intuitive to the design of SSO.

+1 : LINXENS company is also requesting this feature