Settings and activity
1 result found
-
675 votes
Hi everyone, we appreciate all the feedback and votes on this idea. We know using Microsoft Entra ID SSO is now common practice for some businesses and being able to access Xero via a native integration with Entra ID would streamline how your teams log in and get set up in Xero, as well as help in managing access for larger teams and keeping things secure.
Our product team have been working with a small limited group of Partners to develop SSO capabilities. Though we can't give any definite timelines yet, we’ll keep this thread updated with news. Thanks
An error occurred while saving the comment An error occurred while saving the comment 
Andrew Anderson
commented
Yes, I concur with everyone else who is requesting a standards-based implementation that will work with any identity provider. Please do not lock the implementation into a single identity platform.
And I agree that it would be a solid addition to Xero to improve the RBAC granularity available so that the accounting functions can be partitioned beyond just the four user roles that are available currently. This is why I had suggested that Xero look at what Stripe did in its SAML implementation to drive permissions based off the SAML Attributes from the IdP.
An error occurred while saving the comment Andrew Anderson
commented
@Chris Okta's SWA is a browser plugin solution that performs credential stuffing into login forms.
While it would permit for using Okta as a launching point, it does not provide the same level of capabilities and (I would argue) security that a native OIDC/SAML solution would provide.
An error occurred while saving the comment Andrew Anderson
commented
Also take a look at what Stripe did in their SSO implementation to handle advisors with multiple clients/organizations, role assignments via attribute mappings, and their EXCELLENT testing and troubleshooting tools that ensure the SSO configuration is working.
Andrew Anderson
supported this idea
·
An error occurred while saving the comment Andrew Anderson
commented
Please add Okta to the list of IdPs that should be supported when SAML SSO is added to Xero.
I think we all want to see SAML SSO available as soon as is reasonable, but "adopting a professional identity provider" is the exact opposite of what is needed. Instead of calling for Xero to dictate that companies use a specific Identity Provider (IdP) platform (365/Entra), the goal should be to support SAML SSO authentication from _ANY_ SAML authentication provider (Microsoft Entra/ADFS, Google, Okta, Auth0, OneLogin, etc). I will be severely disappointed if this feature is launched and only works for Entra.
Also, the SSO standards already exist (https://www.oasis-open.org/standard/saml/), so what is actually needed here is time for the development team incorporate robust eternal authentication feature support into the product.
As for MFA, Xero already supports TOTP-based MFA, and I use it every time I login, so allow me to point you to the MFA setup instructions for Xero that is available today: https://central.xero.com/s/article/Set-up-multi-factor-authentication
For everyone who is berating Xero as "I can't believe in 202x that...", remember that Stripe only rolled out SAML support a year or so ago themselves, so Xero really is not that far behind other SMB financial service providers in supporting 3rd party authentication services. Keep in mind, Intuit does not support native SAML SSO for QBO today, nor does Sage 50 support SAML SSO. You might be thinking about Sage Intacct, but I see that platform occupying a different part of the marketplace at a different price point, and not directly comparable.
The only "support" for QBO is HTML forms stuffing (aka "Forms-based auth" or "SWA" depending on the IdP terminology), so the main competitor in the small business accounting space (Intuit) does not support SAML SSO either. To the best of my knowledge Intuit has not announced plans to support SAML for QBO, so Xero is already ahead of the curve here among its peers.
What I am hoping to see is that Xero is taking the time to do this implementation correctly and that they are following Stripe's example where they allow users and roles to be completely defined in the IdP system and communicated to Stripe (as the Service Provider [SP]) upon every login (https://docs.stripe.com/get-started/account/sso). Under Stripe's design, user permissions are managed centrally at the IdP and access rights are assigned to the user account in the IdP. This is not a trivial change, and is going to take time to implement all of the necessary hooks for this to work correctly.
Xero has already stated that they are working on this barely over 6 months ago. I would rather they take their time and get this implementation right than to rush the implementation to end users and launch a half-baked product. Stripe worked on SSO for 2-3 years before they made it generally available, so give Xero time to get this right and please don't pressure them into delivering a shallow implementation that exists only to check a checkbox to shut up auditors and winds up disappointing those of us who want to see a robust feature set with JIT provisioning and full role assignments that permits for more granular access support than exists today with the "Invoice Only", "Standard", "Advisor", and "Read Only". In my ideal implementation, there will be permission hooks surrounding all major features and functions, with the ability to provision user accounts in the IdP to give very granular access to every feature that is addressable in all of the menus (Sales, Purchases, Reporting, Accounting, Tax, Contacts), as well as file management, and administration functions. This level of work is non-trivial, and not something that one just "turns on".
As someone who works with authentication technology every day, this is not just a matter of spreading magic pixie dust over the code base for it to work. The first step is that Xero needs to define what they want to achieve with the new feature support (hopefully this has been completed by now). Second, they need to define a permission set that will map to SAML attributes to support the functional definition, and validate that the permission set meets all of the design goals. Third, they need to instrument all of the functions to add the permission set checks that work in parallel with the existing user permissions so that non-SAML sites are not impacted by deploying the new feature. And finally, they need to test the new code extensively to make sure that it is working as designed with no corner cases that would allow for unauthorized access via unprotected paths.
For everyone who is trying to pressure Xero into launching a half-baked SSO implementation "because it limits adoption", take a step back and ask yourself what a botched launch of a major authentication feature would do to Xero's reputation, and how that might "limit adoption" far longer than the "we do not currently support SSO, but that feature is in development" answer currently may.