SSO lets you sign in once and move between connected systems without signing in again. Instead of a separate username and password for every application, you authenticate with one trusted provider, and that identity works across everything you’re allowed to access. For enterprise buyers reaching a supplier’s portal, it means walking straight in with the login they already use at work. No forgotten passwords, no extra account to manage, no friction.
Three reasons, really, and they stack on top of each other. First, access: when a large client has fifty staff who need the portal, you don’t want to create fifty accounts and manage them manually. SSO lets them all in using their existing company login. Second, security: because sign-in is controlled in one place, their identity provider, you can grant or remove access centrally. The moment someone leaves their organisation, their access everywhere disappears automatically. Third, time: fewer passwords means fewer reset requests, fewer support calls, fewer frustrated people locked out at 4 pm on a Friday. For businesses selling to enterprises, SSO is table stakes.
You connect your website to the identity provider your clients already use — Okta, Microsoft Entra ID, Google Workspace, Ping, whoever they trust. Both sides agree on a protocol (SAML or OpenID Connect), exchange a handful of configuration details — sign-in URLs, certificates — and from then on, when someone signs in, the provider vouches for them. GetConnect handles this end-to-end for e-commerce sites. You’ll need a GetConnect Hub license as the base platform, and we take it from there.
GetConnect supports the identity providers most enterprise clients actually use: Okta, Microsoft Entra ID (previously Azure AD), Google Workspace and Ping. Because these work through shared standards — SAML and OpenID Connect — we can often connect to others too. If your clients use a provider that isn’t listed here, ask anyway. Support usually comes down to the protocol it uses rather than its name, and the GetConnect team can confirm for your setup.
Okta acts as the identity provider, your e-commerce site acts as the application. You create an application entry in Okta, choose a protocol (SAML or OpenID Connect), and exchange configuration details — the sign-in URL and a certificate or client secret — between Okta and your site. GetConnect handles this for e-commerce portals, so users in your clients’ Okta directories can sign in with their existing Okta credentials. Once it’s set up, adding or removing a user is done in Okta, and their access to the portal follows automatically.
Microsoft Entra ID (previously Azure AD) works as the identity provider. You register your e-commerce site as an application in Entra ID, pick a protocol — SAML or OpenID Connect — and share the sign-in and certificate details between Entra ID and the site. GetConnect connects e-commerce portals to Entra ID so people in your clients’ Microsoft directories can sign in with their usual work accounts. Because so many organisations already use Microsoft 365, Entra ID is one of the most common providers we’re asked to connect.
“Azure SSO” usually refers to Microsoft Entra ID, which was renamed from Azure Active Directory (Azure AD) in July 2023. Microsoft brought it under the broader Entra family of identity products, but the service itself — its features, licensing, capabilities — stayed exactly the same. The integration works the same way: your site is registered as an application in Entra ID, connected using SAML or OpenID Connect, configuration details are shared, and users can sign in with their Microsoft work accounts. If your organisation still calls it Azure AD, that’s the same directory.
Google Workspace acts as the identity provider, letting users sign in with their existing Google work accounts. You set up your site as a connected application in the Google Admin console, choose SAML (or OpenID Connect where supported), and exchange the sign-in URL and certificate details between Google and the site. GetConnect connects e-commerce portals to Google Workspace so staff in your clients’ Google directories reach the portal without a separate login. Access is then managed from the Google Admin console, right alongside their other Google services.
Ping (PingFederate, PingOne) acts as the identity provider. Your e-commerce site is set up as a connected application within Ping, using SAML or OpenID Connect, and the two sides exchange the details they need to trust each other. GetConnect connects e-commerce portals to Ping so users in your clients’ Ping directories can sign in with credentials they already hold. Ping is common in larger enterprises with more detailed access requirements, which is why we’re regularly asked about it.
SAML (Security Assertion Markup Language) is a protocol, not a provider. It’s the shared language that many identity providers — Okta, Entra ID, Google Workspace, Ping — use to pass identity information securely to a website. When a user signs in, the identity provider sends a signed “assertion” confirming who they are, and the website trusts it. Because SAML is a standard, GetConnect can connect to most providers that support it, even ones not listed by name. In practice, you exchange a small set of details — an entity ID, a sign-in URL, a signing certificate — between the provider and the site. If your provider supports SAML, that’s usually enough to make a connection work.
Magento 2 (Adobe Commerce) can be connected to an identity provider so enterprise buyers sign in with their existing company credentials, not a separate Magento account. This is done by adding SSO to the store and pointing it at the provider your clients use, through SAML or OpenID Connect. GetConnect adds SSO to Magento 2 stores and connects them to identity providers like Okta, Entra ID, Google Workspace and Ping. You’ll need a GetConnect Hub license as the base platform, then the SSO product manages the sign-in connection for the store.
WordPress — often running WooCommerce — can be connected to an identity provider so users sign in with their existing company accounts, not a separate WordPress login. The site is set up to trust the provider, using SAML or OpenID Connect. GetConnect adds SSO to WordPress sites and connects them to the identity provider your clients already use. This runs on a GetConnect Hub license, with the SSO product managing the connection between the site and the provider.
User attributes are the pieces of information an identity provider sends about a person when they sign in — email address, staff ID, department, role. These attributes can be mapped to fields on your e-commerce site, so the right details follow the user in automatically. A common example is linking a staff ID to an email address, or passing a user ID through so orders can be tied to the correct person in your accounting system. GetConnect maps the attributes your provider sends to the fields your store needs, so information stays consistent between systems. If there’s a specific attribute your clients rely on, it can usually be included.
With SSO, most user management happens in the identity provider, not on the website. Adding, removing or grouping users is done centrally, and their access to the portal follows from there. This is why larger organisations favour SSO — control stays in one place. On the store side, users signing in through SSO can be organised into groups, and access can be shaped for those groups — for example, allowing certain staff to see particular areas of a portal. GetConnect sets up these groups and restrictions so the right people reach the right parts of the site. If access needs to differ between teams within a client’s organisation, that can be built in from the start.
Because SSO tells the website who a user is and which organisation they belong to, that information becomes your signal for what they should see. Show specific products or categories, hide items that aren’t relevant to a particular client, apply agreed pricing and discounts for a given organisation. A buyer from one company might see their own negotiated prices and a product range built for them. Another company sees something completely different. GetConnect uses the details passed through SSO to shape this experience per organisation. If your clients expect their own tailored view, that’s built into the design.
For businesses selling across countries or regions, SSO carries the information needed to give each user the right experience. Based on the organisation or location details passed at sign-in, a user can be routed to the correct regional site and shown settings that match their region. GetConnect connects multi-region setups to your clients’ identity providers and uses the details from sign-in to place each user in the correct regional context. This works alongside routing users to the correct website, and regional settings like language and currency all follow from there.
The information passed at sign-in — organisation, country, region, whatever your provider sends — becomes your signal for what a user should see. A buyer from Paris sees prices in EUR and content in French without being asked. Someone from Tokyo gets JPY and Japanese. GetConnect maps those details to your store’s language and currency settings, so defaults land right the first time. If your clients span multiple regions and you’re tired of everyone having to click through a language selector, this is how you stop.
Purchase order payment lets a buyer place an order against their company’s account and pay through an agreed invoicing process, rather than entering card details at checkout. It’s standard in B2B buying — procurement and finance handle payment separately from the person placing the order. Because SSO identifies the user and their organisation, it can be used to enable PO payment for the right buyers. Show a “pay by purchase order” option only to approved companies. GetConnect connects SSO to PO payment so approved buyers check out against their account. If your clients buy on account rather than by card, this can be built in.
Here’s the clearest way to think about it: SSO is who you are, PunchOut is how you buy. With SSO, a user reaches your site using the credentials they already have, no new account needed. With PunchOut, a buyer starts inside their own procurement system (SAP Ariba, Coupa, whatever their company runs), clicks “shop here”, builds a basket on your site, and that basket goes back into their procurement system for approval and payment. SSO handles identity. PunchOut handles the buying journey. Many large clients use both, because they solve different parts of the problem.