@Jim Pickering - Thanks for testing it, at least it means I'm not going mad! Were you talking about the setup on the Atlassian end or the Azure end? I looked at both and didn't see anything either - From the link above that I posted I am still quite sure that Atlassian needs to be managing it themselves.   I also found this link - https://azure.microsoft.com/en-au/resources/samples/active-directory-dotnet-web-single-sign-out/ -  which is a sample app that performs the sign out using a cookie-based method, which again would need to be something Atlassian implements.  Hopefully they will look further into this!

–

@Kris Hen - That is an interesting thing you've discovered. We are using SAML with Azure AD and we get the login error just as your described. I reviewed the SSO Setup and there is no place to even indicate a Sign-Out URL.

I haven't found anyone already commenting about this, but is anyone currently using SAML with Azure AD and finding that if a user logs out of (in our case) confluence, it doesn't log them out at the Azure AD end? This means that if a different user on the same machine tries to sign into confluence, it tries to pass the azure AD login information of the previously logged in user, resulting in a mismatch and a login error - this is quite frustrating as there is no simple way to log out the previously logged in user's Azure AD account! It looks like Atlassian should be doing something like the following: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-single-sign-out-protocol-reference but I cannot say if they are doing something like this and it isn't working, or they haven't got around to supporting this properly as yet...

JIRA Capture needs to support SAML logins via Azure AD as well. We have this functionality working with our verified domain for JIRA Software, JIRA Service Desk, and Confluence in Atlassian Cloud. JIRA Capture requires non-SAML Atlassian login though, which we wanted to avoid having our Testers having to fuss with.

We are in process of evaluating JIRA Cloud. Currently we have JIRA Server for 2000 users. I was looking at this feature request and the instruction to setup SAML for cloud. We use PingFederate as our SSO solution and it seems you mention it on the article with comment that its coming soon. Do you have ETA on when will it be available? is there anyone who have successfully configured SSO with PingFederate for JIRA Cloud and Confluence Cloud?

My company has two JIRA Cloud accounts. One is a pilot account (siteA.atlassian.net) that needs to continue until it can be moved into the new full company account (siteB.atlassian.net). The full company account (siteB.atlassian.net) needs to have SAML enabled, which will work fine, but it makes it so the users of the pilot account (siteA.atlassian.net) are unable to login. Can SAML be enabled for both sites?

I'm looking at authenticating our Service Desk customers via SAML SSO against our IdP.

I was looking at the documentation on this page:

https://confluence.atlassian.com/cloud/saml-single-sign-on-873871238.html

Seems like in order to enable SAML, I need to claim my domain(s). As far as I can tell, only logins belonging to the claimed domains will trigger SAML SSO (conversely, any login that does not belong to a claimed domain will not be able to log in via SAML). Is this assumption correct?

Say my company's domain is thiscompany.com, I claim that domain and enable SAML SSO on my cloud Service Desk. My customer's email is jack@anotherdomain.com. Will he be able to log in via SAML?

If not, how do I enable SAML SSO such that my customers can use their own email address to sign in to Service Desk?

Thanks in advance!

Are there plans to adjust current functionality to better support multiple tenants sharing accounts? The way domain verification/ownership takeover works is flawed if your company uses vendors who may also have their own Atlassian Cloud environment.

We have vendors who access our environment with their company email credentials on domains we don't own. We should able to funnel these through our SAML provider, our source of authorized vendor account information, for authentication without impacting their own companies Atlassian Cloud account.

An example of how this should be handled is how New Relic handles SAML, its on a per-account bases not per-email domain basis. When you toggle between different accounts within New Relic, if necessary, you will be re-prompted for authentication through the appropriate provider (depending on if the account is authenticated by New Relic itself or by a SAML provider).

Okta support is coming in Preview Release 2017.10, which probably means we're a few weeks away from Okta production release.  https://support.okta.com/help/Documentation/Knowledge_Article/Okta-Preview-Sandbox-Release-2017-10

@Thomas

The catch 22 you described is actually how the SAML spec works, Okta just hides that with OAN (Okta Application Network) applications.

mrussell@atlassian.com any updates?

Hey Everyone,

We've been using JIRA with Okta using the Generic SAML2 application in parallel with the JIRA Cloud application for provisioning (see #3 for details).

Steps should be standard for creating a generic SAML2 app, except for the following:

1. From what I remember, Atlassian has the SAML2 process backwards causing a catch 22. You'll need to create a Generic SAML2 app, but you will need to leave this half empty so you can generate the details to hand over to JIRA. From there, you'll be able to generate the rest of the details for Okta.
2. Default relay state should be set to your JIRA cloud instance with the trailing / included (i.e.: https://tickets-r-us.atlassian.net/).
3. Make the Okta-verified JIRA Cloud SAML2 app hidden to your users since you'll need to maintain two apps in Okta.

Our global team have been using this in production for about a month without an issue, with the exception for an unscheduled JIRA Cloud outage that coincided on our SSO cutover date/time.

For testing, keep in mind that when you do switch it on and intend on shutting it off again, anyone that has completed the JIRA SSO onboarding step will need a password reset once it's turned off.

Also, the catch 22 in the above point #1 is likely the dependency that's holding up Okta from adopting it. I'm guessing Okta & Atlassian are going back and forth on changing the process in JIRA to eliminate this catch 22. If you have an paid Okta account, you can contact the Okta support team with the Okta-internal ticket REQ-7770 to add more weigh to the importance of the issue on their end.

Hopefully this helps move this along. Happy to send over screenshots over LinkedIn if anyone has questions.

Thomas Madej
Console Connect
https://consoleconnect.com/

Any update ?

Hello, A few questions about this release:

1. When will you have setup instructions for Okta? An ETA would be good to so that my company can plan internally (we're on Okta and many of your Cloud products and would LOVE to use this).
2. Will this SAML integration cover all the products you offer, specifically Jira Software, Jira Service Desk, Confluence, and Hipchat? These are the products we've invested in (+ Portfolio but we don't see a need for SAML for that) and want to leverage this for all of them.
3. Do you need any test customers? We'd be happy to volunteer!

Thank you!
Tonya Mompoint
CareerBuilder

@mrussell@atlassian.com 
The users have verified email on the domain. We still have the same issue with those users.

Also we noticed that, the users who were able to login via SAML no longer can login, however, if they use their previously cached/old credential they can login successfully.

As of now, all the SAML users get the following error when try to login:

While we did not make any changes to the setting, this happened. The troubleshooting shows that we get a valid token but when redirected to Atlassian the request is malformed. We use Centrify with custom SAML application.

I had made sure that all the attributes are mapped, including the nameid to be present as email. The refer url goes to https://id.atlassian.com/login/saml/acs .

@mrussell@atlassian.com  If there are no plans on removing the Login with Google button from the login screen is there a way we can disable users from logging in using Google authentication. Currently users can either use SAML or the Google button to log in even after disabling the connection to Google Apps.

I got the same error as @joe.dropkin1931291160, there's no signle sign on option as we're already using Atlassian account.

@Joe, I had that error when testing in Okta as a generic SAML2 app. You missed a step and need to enable Single Sign-on in JIRA.

I set up a generic SAML2 app in Okta and could not get this to work.

@Matthew Russell I've communicated to Okta support and the feature request is internally tracked at Okta with ticket REQ-7770. I would recommend that Atlassian and all it's customers communicate to Okta to expedite the connector by referencing this ticket number.

They've communicated that the work-around currently is to provision a generic Okta SAML2 app and configure JIRA to use those details. However, if you use lifecycle management, this workaround requires you to maintain two apps within Okta, one for provisioning and one for SAML2 auth.

Sorry parker.despain699968528, I've been in touch with Okta multiple times since your original question, and status hasn't changed. They're still in progress with their connector. They suggested for those interested to send an email to support@okta.com or open a case directly at https://support.okta.com/help/open_case. This is not really in our control at this point - we're as keen as you are to see it available. 

sracherla969129257 - I'll assuming you're looking at testing while Atlassian account is enabled (Single sign on is turned on). Deleting a SAML configuration does not send password reset emails. If, however, someone goes through login while there is no SAML configuration, they will be able to login with their password (or able to set a password with password reset). Please be aware that while you're testing with your Test IdP, all logins for your users will be going through that IdP - so you will likely lock out some users. We have better testing capabilities in mind for a future enhancement. 

hairom1715481686 - If the existing Atlassian account has an email on the domain you have verified, this should enforce SAML for them. Are you still experiencing this issue. There are a few valid edge cases that explain a failed SAML authentication. If you're still experiencing it, I'd recommend raising a support issue so we can investigate. 

So is that a No!!! on the Okta thing, or are you just ignoring us to be hilarious?

^^ I'm waiting for the exact same thing, fingers crossed...

Please provide on update on SAML for okta.

Can an update be provided for when this will be available for Okta? 

@mrussell@atlassian.com
We have 2 idp instances- idp Test and idp Prod
SAML implemention workflow:

1. Implement idp test
2. Test the implementation
3. Delete the idp test
4. Implement idp Prod

How will the end users/admins be affected by this? Will the users get a password reset email or go back to Atlassian account password when we delete the SAML configuration?

Thanks.

Yeah.  Mine is working today as well.

I used Chrome. After contacting Atlassian Support, this was resolved.

I used Chrome, Firefox, and IE

stephen_brile1875246223 & dfriedman722787694 - what browsers are you using? 

miller.jira699748083 - Deleting the SAML config won't send a password reset. It will be possible for people who've successfully logged in with your SAML to have no password set on their Atlassian account, but they will need to perform their own password reset. If you turn of Single Sign on, you are pointing your site back to our legacy login system, and anyone who has successfully authenticated with an Atlassian account will receive a password reset in that case. For your mismatched email question, existing domain users will not be able to authenticate, though they will not be deactivated. I hope that answers the question?

mreilly326238220 - The main component of support for ADFS comes in the form of documentation from Microsoft. Since Microsoft are not planning on providing documentation / configuration guides, we don't want to set an expectation that our support engineers will all know the in's and out's of ADFS to help you get set up. Microsoft have recommended Azure AD as the solution with ADFS. 

For troubleshooting if I delete the SAML configuration, will the users get a password reset email or can we still implement SAML again without effecting the users? 

^^ I just submitted a support ticket about this issue.

When I click the verify button from my domain, I do not get a window that lets me download the .html verification file.

I see that email id's are case sensitive, what if the email id's do not match?
Will the existing domain users be deactivated?

I wonder: Why no official support for ADFS as an IdP?

Per: https://confluence.atlassian.com/x/bJlCMw 

"We don't officially support ADFS, so we recommend using Azure Active Directory instead."

sracherla969129257 - you are correct. The implementation on your DEV instances will impact login at your PROD instance. 

nmoore@co.pierce.wa.us - To add to Russell's point, my language may have been ambiguous - the users are provisioned automatically upon arrival at your site. So of the 2500+ users who can authenticate with SAML, only those 150 that arrive at you Atlassian site will have accounts created for them, when using domain restricted sign up in combination with SAML.

DevReports195286775 - it should be your IdP password. Your Atlassian account password is now only used for API authentication. 

******************
Testing Instructions:

1. Open a new incognito window.
2. From your site's login screen, sign in with an email address on one of your verified domains.
3. Confirm you are signed in correctly and have all the expected access.

******************
After implementing SAML, do you have to use your Idp password or Atlassian Account password to login

Thanks.

@ Nate Moore

I dont know what SAML provider you are using however with Azure you can assign apps per user or group (if you have Azure AD Prem) and that can be a control mechanism...also with ADFS you can restrict to domain group who is authorized to leverage the appropriate claim

Matthew - regarding your comment on Jan 2 about automatic provisioning:

If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

What is the solution for when you're not providing accounts for your entire enterprise?  For example, we have 2500+ users who can authenticate via SAML, but only 150+ who need JIRA access.  Is there no mechanism for only using SAML for authentication?

@mrussell@atlassian.com 

Thanks for the info.
"If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites" 
Does this mean even if I implement SAML on a DEV intsance, the users will have to use their Idp password to login to their PROD instance?

Thanks!

@Matthew Russell: Fantastic. Enabled domain restricted signup and provisioning works fine. It would be even better if it skipped that middle step of hitting the login screen, but it will work for now.

Another feature I might suggest for the future is reading the group memberships the SAML provider can push across and automatically place the user in those groups if they exist on the Confluence side.

Thanks!

brett.wiard980557619 - we are close to having IdP initiated SAML complete - we hope to have that incorporated before we go to public beta. Timescale here is days/weeks. 

aaron.pollock1141433412 - Thanks for your feedback! We're looking at improving the configuration page to include a feedback button. For your questions: 

• We have an ability to suppress the invite to a user coming soon also. 
• There are no plans to remove the Login with Google button from the login screen, as this login screen is used across all of Atlassian account - it is not customisable per customer.
• If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

sracherla969129257 - If your PROD instance does not yet have Atlassian account enabled, you can safely test there (SAML configurations only apply to login with Atlassian account). If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites. This is a quirk of the single-account nature of Atlassian account that we are looking at solving with better test capabilities within the configuration. 

@Brett Wiard

I had it running for a bit and when it was enabled, if I went to domain.atlassian.net it piped me over to the SAML page...but post login it had me do a quick validation...

I would love to be able to an IDP into it so I can 302 page and make it friendly, ie atlassian.internaldomain.net and that lands on a page to log into pass credentials into the system, no email, etc...did it with new relic and ADFS (ADFS is still unsupported for this beta)

Are there plans to have SAML send the user to <domain.atlassian.net> instead of id.atlassian.com? This causes the user to have to enter their email address, then click the <domain.atlassian.net> URL inside their Atlassian profile page.

Is there a place for customer feedback surrounding the SAML features? Specifically, I'd like to see the following implemented:

• No invitation sent when adding a user that will be logging in with SAML. There's no need for them to have that, as they'll just be clicking the Atlassian and/or Confluence button in our SSO provider.
• Removal of the "Log in with Google" button on SAML enabled sites.
• Auto-creation of accounts for people that log in with SAML which get placed into the default "confluence-users" group.

I love a hands-off deployment where I wouldn't have to send invites to every employee (That when clicked, sends them to a page that tells them they have no access to view it).

Cheers!

Hi *

there is new ticket for SAML and standalone Server installations.

https://jira.atlassian.com/browse/CONF-45634

Please vote

KR - Wolfgang

@Wesley_Kirkland

while I did read over the rfc governing email and SMTP messaging, I feel this is not applicable here as we are dealing with SAML protocols and not messaging...I worked with Atlassian product support on this and they did confirm they did this by design...

Russel,

The case sensitivity is probably coming from this RFC https://www.ietf.org/rfc/rfc5321.txt

So I was able to get ADFS online with Atlassian SAML, its pretty straight forward but there was some caveats and a possible bug that gets in the way

1) caveat - nameID must match AtlassianID down to the case...ie the final transform from the system must align to what Atlassian has for your ID, jdoe@test.com=jdoe@test.com, JDoe@test.com will not work

2) bug - Currently if you have a managed domain (which most of us do), you can not update your email case...they have that in flight, so you would need to update UPN or what ever source is for nameID transform

3) IdP direct auth - some sites you can do adfs.test.com/adfs/ls/IDPInitiatedSignon.aspx and select the provider or simply have a 302 page to https://adfs.test.com/adfs/ls/idpinitiatedsignon.htm?loginToRp=identifier...this does not work quite yet...historically this is hit or miss with some of the ones I have done and usually takes some more work to get correct info or add another SAML page

4) Secure Logoff - no SAML url posted yet, since this is beta not a big deal

ADFS Fun

creating the ADFS claims connection wasnt too hard since they give you the pertinent info in the saml page, however there is no XML or web site to pull the config from...so manual fun, still not that crazy...

below are the fields that need to be in place for the site

Next is the Claims/Transforms

and your done...

just remember the output of the nameID in email format MUST MATCH the Atlassian ID to include case...this is by their design...

one tool to help is a plugin for chrome (https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm)

hope this helps some folks...but remember at this time ADFS is not officially supported by atlassian, so enjoy at your own risk/sanity

I successfully configured SAML with Azure Directory. I faced one Issue:

• After finishing configuration I was not able to login with an AD user - error was: Reply address "https://id.atlassian.com/login/saml/acs" does not match the configured value "https://id.atlassian.com/login" (message is not 1:1)

• I fixed it by setting the Reply URL in Azure Active Directory configuration to "https://id.atlassian.com/login/saml/acs" (under advanced settings)
  

All,

I am still tinkering with ADFS however there is a small catch that may not be explained quite right...if you disable, it states everyone will get their password reset...not exactly true, its everyone that has successfully authenticated VIA SAML will get reset...could lead to some moments of panic or sudden resume updates

While I was able to get ADFS to work with jira.atlassian.com I experienced a new error "Unfortunately we currently do not support change in email in your Identity Provider."

We have hundreds of users and we really need this but I am afraid to touch this beta

@ mlavigne 

on my instance/tenant when I switch it off SAML, all is good...but when I want to post to boards on jira.Atlassian.com it wants to authenticate me to id.atlassian.com which has my domain flagged for saml so I have to do id.atlassian.com/logon?saml=false

so for all my users, life is back to normal...its only when a user hits id.atlassian.com...

@russel, are you saying you were NOT able to disable it and have to always pass in saml=false now?

@datagenic

I am also playing with ADFS3, I got it to pass the data but stated no UserID...I was doing Email (and also tried UPN) to email ldap match then doing a transform in the claims from email to Name ID and format email...also added the additional surname and given per the docs but no love...no errors in adfs either...I disabled it and fwd'd them my SAML logs from my plugin from chrome...I also tried IDP initiated from /adfs/ls/IDPInitiatedSignon.aspx and that just basically said "huh"? I think the endpoints are correct, just the claims or something is off however wouldnt be surprised if you we need to do custom xml for claims

also worth noting after I turned off SAML for the instance, if I went to ID.atlassian.com again it defaulted to SAML for me, had to use the logon?saml=false flag

@Mike https://id.atlassian.com/login?saml=false It's in the document.

I've tried this with ADFS (guessing some endpoint URLs and mappings based on other SSO plugins etc) and had no joy, but instructions are not yet available. A step in the right-direction Atlassian, now we just need SAML for BitBucket too please.

Has anyone turned this on yet? I am worried about the enforcement by domain. What happens if its configured wrong and I can no longer log in as an admin. Seems like a mess waiting to happen...

Just FYI:

• SAML single sign-on for Atlassian account

Just received the beta invite. 'Azure instructions coming soon' FFS

tracy.rhinehart yes the SAML beta is running SAML 2.0

What version of SAML is the beta? SAML 2.0?

If I enable the SAML beta is it enforced for the verified domain or is it optional? 

Nice to see the beta starting up, now let's hope that they do the same for LDAP, then my company would be able to seriously consider Atlassian Cloud apps.

Hi thomas.hadig Just passing by to know if you were able to catch this update of the private beta for SAML?

In case you missed please, fulfill the form in order to participate .

-------------------

Best Regards!

Daniel Brito | Atlassian Cloud Support

Please feel free to register to take part in our SAML Private Beta as mentioned in the update at the top of this issue. We would welcome feedback on the feature and the process to enable SAML for your Atlassian sites.

We are now investigation alternatives for Jira, Asana and Phabricator.

I wouldn't hold your breath... I've been waiting 5 years for this. Unlikely to happen anytime soon I suspect. There are other decent hosted tools that are equal to Confluence and JIRA.. (Asana et al).

From Wikipedia: "Atlassian also began a now-popular tradition at software companies where software developers can spend 24 hours tackling any problem they like four times per year. Atlassian calls these ShipIt Days".

So even if Atlassian Management don't care about their customers, it's clear the developers don't either or this would be fixed by now. JIRA is the Flagship product for Atlassian, and along with issue ID-79 for LDAP integration which has been open for 6 years  this one is stinking up the place.

I'm very familiar with Crowd and have used it in the past, sadly it does not help... as you've noticed.

@Dennis Portello - they even have their own IdP solution (https://www.atlassian.com/software/crowd), so it's not like they don't have a very good grasp of SAML / OAuth. It's just very odd that it's not integrated into their cloud products, where it would benefit most.

Yes - can we have an update please!

100% agreed with the above... I've used https://github.com/bitly/oauth2_proxy to provide Azure AD authentication to simple sites/applications, and I've integrated oauth2 libraries in apps we've built ourselves. SAML and OAuth2 can be a little mind numbing, but it's not rocket science. There are tons of Java libraries out there that Atlassian could integrate with their products. I just don't get it... smh

100% agreed. We actually started setting up Crowd, on a (wrong) understanding that it would allow us to do SAML auth to the Atlassian cloud apps... We were wrong, and very nearly terminated the trial of JIRA. As it stands now, we're only licensing about 10-15% of the users that we would otherwise use if full SAML was available.

We currently use Azure AD (or ADFS if really needed) for our SAML auth, and integrate with half a dozen other cloud services already. Not just a "nice to have" anymore, but a need for businesses like ours for full adoption.

Yes, what Dylan said.  An update and timeline guidance, please.

And me as well. Especially interested in integration with ADFS/Azure AD. This is a requirement to even investigate using JIRA cloud for us. Is it possible to get an update on progress for this feature?

Add me to the chorus of people that need SAML support.  Jira is the only SaaS product we use that does not currently have it.  I cannot realistically expand our usage of Atlassian tools until this exists.

I've given up on Atlassian as a company wide tool. It's been relegated to a small department within IT where I don't need to worry about managing large number of users.

JIRA is the last of our apps that doesn't support SAML... Seriously Atlassian? Wake-up we are in 2016 and most companies don't care about the iDP features you are or will provide, they need to integrate with their current iDP platform...

Bump... (Asana supports SAML btw)

We're having a hell of a time getting our password synchronized from our iDP (Okta) via SWA and wouldn't you know it, SAML would solve our problem.

Unfortunately, I have discovered that Atlassian does not support SAML ATM.

Tisk, tisk...

Time is ticking Atlassian and it's high time this standard feature be implemented ASAP. Wouldn't want Atlassian to market share to a competitor simply because of SAML support.

ESSENTIAL FEATURE

I'd like to adhere to @msholmes comment.

We are implementing a wide DevOps platform, with cloud and on-premise tools, many of those can authenticate with our SSO platform(Ping Identity) via SAMLv2.

Almost all of the newest tools have this important feature.

This feature is essential.

• MUST defer authentication to our domain's IdP
• SHOULD support SAML attributes from the IdP to the Atlassian application to auto-create accounts on first successful sign-in (i.e. pull sn, givenName (or displayName), mail)
• SHOULD support administratively configurable attributes mapped to Atlassian application (e.g. presence of "ConfluenceUser" gives access to Confluence, and "JiraUser" to Jira, etc; absense removes access)

SAML IdP administrators know the benefits of these capabilities for all parties involved.

We are looking at cloud-hosted upgrade options for our 2000 users, SAML/ADFS or SAML/KeyCloak is a requirement for us to minimize the acount administration burden and security risks.

SAML/ADFS/AzureAD integration is a must. JIRA is the only cloud suite that doesn't fit into our current setup and causes much friction for our users. We have O365, and use JIRA for JIRA,Confluence,Bamboo,Service-Desk. We'd like to understand how Service-Desk would fit into this mix also with non-SSO users (ie. customers) self-registering, and our internal users using SSO.

Please support SAML/ADFS soon!

We are looking at cloud-hosted upgrade options, SAML/ADFS is a requirement for us.

I agree with Dan, SAML and OpenID support are necessary.

I would hope they work on both SAML and Open ID. My project is a collaboration of many separate entities and I need to tie them all together. Hopefully we will have that in the future. We had to purchase the server based one and come up with a solution ourselves.......

I would love to test an Atlassian built solution.

Dan

In this day and age, why head for a dated protocol like SAML and not the more modern Open ID Connect which is gaining traction?

If we were playing Texas hold 'em, your first question would be classified as "tell:" "Atlassian believes a single account for end users will foster lower friction collaboration within and between teams everywhere, and that this is a highly desirable concept for our customers."

Ultimately, who controls the work that's produced is the question. If you're taking the GitHub approach (where individuals have their own GitHub usernames/passwords and are invited to join a particular company and collaborate on projects), that's one approach. Another approach is that the company that said individual joins is the IdP (Identity Provider), and once said individual leaves that company, (s)he leaves that identity (and work created with it) behind.

Both approaches have their merits. The GitHub approach to identity management ensures that an increasingly mobile ^{(cough millennial cough)} workforce can retain their individual identities & side projects wherever they may roam. The "traditional" corporate approach all but guarantees (at least in the eyes of the employer) that "what's produced here stays here." When you leave the company, you forfeit your access to your identity and the work you produced while you were under their purview.

I believe we're each entitled to our own opinions on who owns an individuals online identity as it pertains to collaboration tools, especially in the age of an increasingly mobile workforce.

What's at issue here is how authorized individuals gain access to corporate data.

If Atlassian is the Identity Provider (hereafter referred to as the IdP), and an individual's identity is "invited" to access corporate data, there are no restrictions on:

• Two-factor authentication
• Time-based access
• Geography, conditional access, etc. (depending on the requirements of the SAML IdP)

...whereas, if the company is the IdP, they can dictate the above requirements by refusing to issue a SAML token to their repositories/wikis/etc. to a user who does not meet their security requirements. This should not be understated--it's important from a security POV.

Furthermore, locking a user out of that company's directory would effectively prohibit access to said company's intellectual property by virtue of the fact that the company is the IdP. With so many disparate systems in use today, will 100% of admins remember 100% of the time to revoke an ex-employee's access to the company's repositories/wikis/etc. upon their departure?

Not a sermon, just a thought... ^TM

I took the survey to mean what would I pay for a combined Jira license, Confluence license, and SAML, so I based my answers on that. Do we expect they were asking for costs of just the SAML feature?

I'm shocked that after such a looooong time of building this that they are now even considering it as a "Premium" offering. Yes, I get that they had to do a bunch of infrastructure work to enable this. BUT, these:
• SAML 2.0 SSO Support
• Custom Domains
• 2FA Auth with optional SMS
• Consolidated Billing
are a core component of what any cloud offering in 2016 should have.

It is NOT a premium thing at all, period!

@anthony - absolutely - I got the same survey, and happily answered $0 for each of those.

Why on EARTH would I pay MORE for a consolidated bill?!?!? Honestly!

The reason I'd pay $0, and therefore wouldn't purchase those features, is that I expect those features from a SaaS offering. Also, I have no plans to extend my use of Atlassian Cloud, and in fact are actively migrating from it.

I was hoping for more free form text boxes where I could explain to them that this should not be a separate "premium tier" because after all THEIR SALES TEAM TOLD US THOSE EXACT FEATURES WOULD BE AVAILABLE SHORTLY WHEN WE FIRST BOUGHT INTO THE CLOUD VERSION.

I don't see any reason why I can't share what they sent me if they do truly value our feedback, unless the URL is unique to me. Give it a try:

Hello,

Your feedback has been instrumental in developing and improving JIRA and Confluence, and today we invite you to help us understand the value of our product.

We believe pricing and value should not be a one-sided conversation, so please take a minute to answer our survey. We're excited to receive your feedback!

https://www.surveygizmo.com/s3/2733520/Atlassian-0202

Yes - how do we get an invite to that survey??

I hope I get an invite, that would be so much fun

I was just invited to participate in a survey asking how much we would pay for "JIRA/Confluence Cloud Premium" with:

• SAML 2.0 SSO Support: Configure SAML authentication via IdPs such as: Okta, OneLogin, Centrify, Ping etc. and any other providers that support SAML 2.0.

• Custom Domains: Use a customer-provided domain, e.g. yourdomain.com for the Atlassian service.

• Two Factor Authentication with SMS: Enhanced security multi-factor authentication with optional SMS validation.

• Consolidated Billing: Manage all of your Atlassian services on a single bill.

So, it seems as if this feature may be in the works, but Atlassian wants us to pay more for it by calling it a "Premium" feature.

Not all of us use Google Apps. SAML is needed badly.