Skip to main content
[email protected]
Remote-first from Hanoi
Operated by Netbase JSC

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Integrations

Single sign-on for print portals: SAML and OpenID Connect

Single sign-on lets print-portal staff authenticate through the organisation's SAML 2.0 or OpenID Connect identity provider instead of a separate password. The identity team controls attribute release, a stable subject identifier, logout behaviour and the group claims the portal maps to roles and cost centres; just-in-time provisioning creates the account, or SCIM keeps it continuously synchronised.

Start a project brief Explore services

Reviewed by CEO, Netbase JSC · Updated 4 Oct 2026

star

Where does single sign-on fit a print portal?

Single sign-on lets staff open a corporate print portal with the credentials they already use for every other internal system, through the organisation's identity provider rather than a password the portal stores itself. The buyer for this page is the identity or IT security team, not the brand or marketing stakeholder who commissions the portal's templates and approval rules: they ask about protocol support, attribute release, session and logout behaviour, and how a leaver loses access, before the portal's look and workflow are discussed at all.

B2B and corporate print storefronts and corporate in-plant print each carry one paragraph on single sign-on as part of a wider account and requisition system; this page owns the protocol detail both link to, so it is written once rather than three times. A procurement buyer without a directory-based identity provider more often arrives through cXML punchout or SAP OCI instead, which is one of the platform pages in the web-to-print integration directory. Single sign-on fits poorly as the only integration on a brief: a portal still needs its account hierarchy, approval rules and pricing designed regardless of how staff sign in.

Key takeaways

  • The identity team, not the brand team, is the buyer for this page: they decide what SAML or OpenID Connect releases and what the portal is allowed to ask for.
  • A stable subject identifier, SAML's persistent NameID or OpenID Connect's sub claim, must anchor the account, because an email address can be reassigned or renamed in the directory.
  • SAML's Single Logout Protocol and equivalent OpenID Connect session management depend on every service provider supporting the same binding; in practice logout is best-effort, not a guarantee that a session is dead everywhere.
  • Group claims carry the organisation's own group names, and the portal maps them to its own roles and cost centres in a table it owns, rather than assuming a group name matches a role name.
  • Just-in-time provisioning creates the account from the first successful login; SCIM provisioning keeps accounts and group membership synchronised continuously, including removing a leaver the same day, which JIT alone cannot do.

How does a login cross from the identity provider to the print portal?

Attribute release. The identity provider decides what it discloses in the SAML assertion or OpenID Connect ID token: a name, an email, group membership, and whatever custom claims the directory exposes. The portal requests a fixed, named set of attributes and treats everything else as absent; the identity team approves that list before the first login, since it is their policy decision.

The subject identifier. OpenID Connect Core defines sub as a locally unique identifier for the end-user that must not exceed 255 characters and is never reassigned by the issuer; SAML's technical overview documents the persistent NameID format for the same purpose. The portal stores whichever of these the provider sends as the permanent account key and treats email only as a contact field, because a reissued email must not detach a user from their order history.

Group claims to roles and cost centres. The token or assertion carries the user's group names as the identity provider defines them. A mapping table inside the portal, maintained by the identity team, translates each external group into an internal role, such as requester, approver or administrator, and into a cost centre; the portal never infers a role from a group name it has not been told about.

Just-in-time provisioning. On a user's first successful login, the portal reads the asserted attributes and creates the account automatically, assigning the role and cost centre the mapping table resolves. Nothing happens until that person signs in, and nothing removes the account when they leave.

Session and logout. A login establishes a session on the portal with its own timeout, independent of the identity provider's session length. Signing out of the portal does not reliably end the identity provider's session, and the reverse is just as unreliable, because that depends on every party supporting the same logout binding.

  • SAML assertion / OIDC ID token

    What it carries
    Subject identifier, requested attributes, group claims
    Where it is decided
    Identity provider, per the released attribute policy

  • Mapping table

    What it carries
    External group name to internal role and cost centre
    Where it is decided
    The portal, maintained by the identity team or an administrator

  • Just-in-time provisioning

    What it carries
    Account creation at first login
    Where it is decided
    The portal, from the token's own claims

  • SCIM provisioning

    What it carries
    Account and group lifecycle, including removal
    Where it is decided
    The identity provider, pushed continuously
Diagram of a login crossing an identity boundary: released attributes resolve a role, and the portal never infers one
Diagram of a login crossing an identity boundary

Why does logout stay unreliable even when SAML or OpenID Connect are configured correctly?

OASIS describes the Single Logout Protocol as a near-simultaneous logout of the sessions tied to one user, carried over SOAP, HTTP Redirect, HTTP POST or the HTTP Artifact binding, and notes that a browser logout commonly needs the front-channel bindings so the browser actually visits each session participant. If a provider only supports a back-channel binding, or a browser blocks a required redirect, that provider's session can outlive the logout request. The practical response is to treat the portal's own session timeout as the real control, and pair single sign-on with prompt directory deprovisioning rather than relying on logout propagation.

Just-in-time provisioning or SCIM: which one, and when?

Just-in-time provisioning needs no integration beyond reading the login token, so it suits a portal with a small or stable user base reviewed periodically. It has one structural gap: a leaver who no longer appears in the directory still has a portal account until an administrator deactivates it by hand.

SCIM, standardised in IETF RFC 7644 as an HTTP, REST-based protocol for provisioning identity data between systems, gives the identity provider a /Users and /Groups endpoint it can call directly, so an account is created, updated or deactivated the moment the directory changes, with no dependency on a later login. It suits a workforce with regular turnover, where same-day deprovisioning is the point, at the cost of building and maintaining the endpoint itself.

Which components and systems are involved?

Single sign-on sits in front of the same account hierarchy, approval workflow and brand-locked template system a corporate print portal already needs. We can build B2B and corporate print storefronts with account hierarchies, permission models, approval workflows and brand-locked template systems, and we provide scoped services for new web-to-print setup, upgrades, migration and software integration for enterprise teams.

Netbase JSC, which operates Web2Print Solutions, has delivered 50+ web-to-print platforms. Web2Print Solutions is the web-to-print engineering service of Netbase JSC. Delivery records cited on this site belong to Netbase JSC; where no delivered example of a capability is published, the page says so rather than implying a record. No single sign-on integration for a named client is published as a case on this site. The default engagement is fixed-scope with written acceptance criteria and priced change control. Managed operations is a separate, opt-in agreement. Client-specific deliverables, access and handover are defined in the engagement contract. Pre-existing software, products, APIs and third-party components remain subject to their respective ownership and licence terms.

Scope this with a project brief naming the identity provider, its protocol, the groups that should map to roles, and whether a SCIM feed already exists.

Discuss your web-to-print project

Start a project brief Explore services

Frequently asked questions

Start a project brief

It can be stored as a contact field, but the account itself should be anchored to the stable identifier the provider issues, because an email address can be renamed or reassigned.

With just-in-time provisioning alone, no: accounts appear automatically but are not removed automatically, so a leaver's access needs manual deactivation unless a SCIM feed is in place.

Yes, as separate login routes mapped to the same account and role model; most organisations run only one, so this matters mainly during a provider migration.

The identity team, through the provider's attribute release policy; the portal can request a set of claims but cannot make the provider send more.

References (4)

[email protected]

Tell us what you need to build, migrate or connect.

Start a project brief