Why Open-Xchange SSO takes more planning than a login setting
Single sign-on for OX App Suite v8 is a platform change, not a login setting. If your staff use OX App Suite for email, calendar and contacts and must sign in with your corporate identity provider, the work involves choosing a login protocol, deciding how sessions and autologin behave, provisioning users and contexts from your directory, and routing sign-in traffic through the Kubernetes ingress. Each of these touches a different team, so the plan has to be agreed across identity, platform and security before any configuration starts.
Start with the protocol question, because the documentation does not treat every component the same way. Open-Xchange documents OpenID Connect for OX App Suite and documents SAML login configuration for the middleware. Your team should confirm with Open-Xchange which path applies to the release you intend to run, whether your identity provider supports that path, and whether any claims, attributes or certificates your provider issues map cleanly to the user accounts that already exist in OX App Suite. Ask for the exact configuration reference that matches your release, not a general guide.
Session behavior is where many SSO projects surprise the business. Identity providers usually set their own session lifetimes and re-authentication rules, while OX App Suite keeps its own session state, backed by Redis in the v8 design. Decide in advance how long a session should last, whether users with shared or kiosk devices need a shorter limit, and how sign-out in the identity provider should reach an open mail session. Autologin rules, which let a returning user skip a login prompt, need the same review with your security team, because they change the risk of an unattended browser.
Provisioning is the third area. Users and contexts must exist in OX App Suite before they can sign in, so you need an agreed source of truth for accounts, a process for joiners, movers and leavers, and a decision on whether accounts are created at first login or synchronized ahead of time. Confirm with your directory and platform teams how group membership will map to OX App Suite contexts, and who approves changes. Finally, the Kubernetes ingress path must pass the redirects, callbacks and headers that the chosen protocol requires, so the platform team should test that path in a non-production cluster before the identity team signs off.
Which parts of the platform SSO touches
Single sign-on touches six places that must agree with each other. Each one either sends a user to the identity provider, returns them to the platform, or stores the session and account records that follow them. Exact configuration keys must be confirmed against the v8 release documentation for your chosen version before any setting is changed.
OIDC login in OX App Suite
OpenID Connect is the login path for OX App Suite v8 when your identity provider issues tokens. The OIDC settings define the issuer, the client registration, the redirect URI and the claim that maps a sign-in to an existing account. Check that the redirect URI matches the public hostname served by the ingress, and that the claim your directory returns is unique per user. A mismatch here usually shows up as a login loop that gives no clear error.
SAML login in the middleware
Where your identity provider speaks SAML, the login settings sit in the middleware configuration. They define the entity ID, the assertion consumer endpoint and the attribute names carried in each assertion. Confirm which login module your chosen release exposes, then test signed assertions and clock skew between the identity provider and the middleware nodes. Both commonly cause failures that look like bad credentials.
Ingress path through Istio or ingress-nginx
Every login redirect passes through the ingress, which decides the hostname, TLS certificate and forwarded headers the platform sees. OX App Suite v8 requires Istio, and ingress-nginx is a basic option only where Istio cannot be used. Check the external hostname, the routing to login endpoints, and that the forwarded protocol header is set so redirects use HTTPS. Hostname errors here also surface as failed redirects at the identity provider.
Redis 7.4.x session storage
OX App Suite v8 uses Redis 7.4.x for caching and session storage, and the default deployment is managed through the littlered operator. Session lifetime and autologin behavior depend on what Redis keeps and for how long, so the topology must match the session rules you set. Decide between the operator default and an unmanaged or custom Redis, and confirm the version your release supports. Sessions held only in Redis end when that instance is lost, so plan persistence and failover early.
MariaDB user and context records
Provisioning writes user and context records into MariaDB, the primary data store for OX App Suite v8 on the InnoDB engine. These rows define which accounts exist, which context each belongs to, and which login name ties each one to your directory. Check the database privileges the provisioning path uses, and the character set and collation expected for account names. Supported lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported.
Helm values per environment
The Helm charts carry the OIDC, SAML, ingress, Redis and database settings as values, so each environment such as test, staging and production can differ only where intended. Keep these values in version control, separate secrets from plain settings, and record the chart version each environment runs. Helm 3.17.0 or newer is required for v8, and a chart upgrade can rename keys, so review the values diff before each rollout.
Choosing OpenID Connect or SAML for OX App Suite login
This table compares the two login paths for OX App Suite, OpenID Connect and SAML, across fit, certificate and metadata handling, claim mapping, testing and documentation currency. Read each row against your identity provider's capabilities, and treat the split approach row as a question to confirm with Open-Xchange before you commit to a design.
| Decision point | OpenID Connect | SAML |
|---|---|---|
| Best fit | Your identity provider already issues OIDC tokens and your team can register a client for App Suite. | Your corporate identity provider supports SAML only, with no OIDC option available for this integration. |
| Certificates and metadata | Client ID, client secret and redirect URI handling. Secret rotation is coordinated between the provider and App Suite configuration. | Signing certificates and identity provider metadata are exchanged. Certificate expiry dates need tracking and a renewal plan. |
| Claim mapping | Map subject, email and group claims to App Suite user attributes. Confirm claim names with the identity team. | Map assertion attributes to the login name and mail fields. Confirm the NameID format and attribute names with the identity team. |
| Testing effort | Test sign-in, logout, session expiry and autologin behavior on every release you plan to run. | Test assertion signing, clock skew, logout behavior and attribute mapping in test before production cutover. |
| Documentation currency | The App Suite security documentation describes OIDC for the product. Confirm the settings apply to your v8 release line. | The operator guide is published under the 7.10.1 documentation path. Confirm with Open-Xchange that its steps apply to your v8 release. |
| Split approach (mixed login paths) | Plan this path only if mixed login paths are supported for your version. Get written confirmation before design work starts. | The same condition applies. Do not plan two login paths for one user base until support is confirmed for your version. |
How to wire an identity provider to OX App Suite step by step
This sequence takes an OX App Suite v8 deployment from a confirmed login path to single sign-on that is tested end to end and can be rolled back. Each step closes with a check that the platform and identity teams can record. Work moves from documentation and identity provider registration through non-production Helm configuration and Redis session storage to a staged production rollout.
Confirm the release and login path
Start by reading the OX App Suite requirements and the OpenID Connect documentation for the release you plan to deploy. Confirm that your Helm version meets the minimum of 3.17.0, that your Kubernetes and Istio versions are supported, and whether your identity provider fits the OIDC path or needs the SAML middleware route. The platform lead records the release, chart version and chosen login path in the change record. This step is done when that record names one login path and each prerequisite has a named owner.
Register the client and redirect URIs
The identity team registers OX App Suite as a client or service provider in your identity provider, using the login path chosen in the previous step. Define redirect URIs for each environment exactly as the OIDC documentation describes, including the non-production hostname. Store the client secret in your secrets manager, out of chart files and version control. This step is done when a test sign-in from the identity provider's own tooling reaches the registered callback without a redirect mismatch error.
Map claims to the mail user
Decide which claim carries the mail user's identifier, such as the login name or primary email address, and confirm it matches the account name that OX App Suite already uses for the mailbox. Ask the identity provider team to release that claim, plus any attributes you need for display name and locale, in the ID token or user info response. Decode a sample token from the test tenant and record the claim names. This step is done when the identifier for a test user matches the existing mailbox login exactly, including case and domain part.
Configure OIDC settings through Helm values
The platform engineer adds the issuer URL, client ID, a reference to the secret and the redirect URI to the Helm values for a non-production namespace, using the keys documented for the middleware OIDC settings. Keep values for each environment in version control and deploy through a Helm upgrade that a second person reviews before it runs. This step is done when the release rolls out, pods reach the ready state, and a login attempt redirects to the identity provider and returns to OX App Suite with no errors in the middleware logs.
Set session storage on Redis
Confirm which Redis deployment backs session storage: the default instance managed through the littlered operator, or a custom or unmanaged Redis that you configure yourself. The supported line for this release is Redis 7.4.x. Set the session lifetime and autologin rules in the values for this environment so they match your security policy, and document both settings. This step is done when a test login creates session entries in Redis and their expiry matches the configured session lifetime.
Test one account end to end
Sign in with one test account from a clean browser and confirm that the token exchange completes. Open the mailbox and check that the session holds the expected user identifier. Sign out, then check that the session key is removed from Redis and that reopening the application requires a fresh sign-in. If you use shared mailboxes or delegated access, repeat the test with an account that has them. This step is done when the logout check passes and the results are recorded against the chart version.
Roll out with a documented fallback
Move the tested values to production in stages, starting with a small pilot group that the service desk can support. Keep a documented fallback login path, such as a local administrator login or a break-glass procedure, and exercise it before any user is switched over. Record the Helm revision so the team can roll back to the previous release if sign-in fails. This step is done when the pilot group signs in through the identity provider, the fallback path has been used successfully, and the rollback has been rehearsed in a non-production environment.
How SSO differs across Istio, ingress-nginx and air-gapped setups
On a cluster with Istio, which OX App Suite v8 requires, the Istio gateway handles the public entry point. Treat this as the reference model. Your identity provider redirects users back to a public hostname served by the gateway, and the session cookie is scoped to the App Suite host that the gateway serves. The trusted issuer URL is the public identity provider endpoint that the middleware validates tokens against. Confirm these points before design sign-off:
- Redirect URIs: register the exact callback URL for the gateway hostname, including the scheme and path expected by your OIDC configuration in the target release.
- TLS termination: decide whether TLS ends at the gateway and whether traffic to the pods is re-encrypted. Mutual TLS between workloads is a separate setting from the external certificate.
- Cookie scope: confirm the domain and secure attributes so the session cookie survives the redirect round trip without being shared with unrelated hosts.
- Issuer URL: use the exact issuer string the provider publishes, since token validation fails on any mismatch in scheme, host or trailing slash.
- Discovery access: confirm that the middleware pods can reach the discovery document and signing keys through your mesh egress rules.
Check every value against the OX App Suite OIDC documentation for your release before you build the gateway resources.
Where Istio cannot be used, OX App Suite offers a basic ingress-nginx option, which is a documented fallback. The ingress path changes shape: the ingress controller becomes the TLS terminator and the entry point for redirects, and no mesh sits between the controller and the pods. This path has fewer built-in traffic controls, so the team should verify each header and routing rule instead of assuming the Istio model carries over. Confirm these points:
- Redirect URIs: the callback must use the hostname the ingress controller answers on, and the ingress host rules must match the registered URI exactly.
- TLS termination: the controller terminates TLS with a certificate you manage. Confirm how the upstream connection is secured and whether it is re-encrypted to the pods.
- Cookie scope: check that the ingress does not rewrite cookie domain or path attributes, and that the session cookie scope matches the single public host.
- Forwarded headers: confirm which proxy headers the middleware trusts, so the scheme and host it sees match the public URL used in redirects.
- Issuer and discovery: the issuer URL and discovery endpoint are reached the same way as in the Istio model, but without mesh egress policy. Confirm outbound routing and DNS from the middleware namespace.
Confirm the fallback with Open-Xchange for your target release, since the supported path and its limits are set out in the requirements and operations documentation.
In an air-gapped or on-premises network the identity provider is internal, so trust rests entirely on addresses and certificates your organization controls. Nothing is reached on the public internet. Metadata, discovery documents and signing keys must be available from inside the network, and Helm charts and container images must be mirrored in advance. Confirm these points:
- Redirect URIs: use internal hostnames that your users resolve, and register them with the identity provider before testing. Public certificate authorities may not issue for internal names, so plan for an internal CA.
- TLS termination: confirm where certificates end and that the internal CA chain is trusted by both the application and the identity provider.
- Cookie scope: set the cookie domain to the internal host and verify that cookies pass through any internal load balancer or proxy.
- Issuer URL: the issuer must match exactly what the internal provider advertises, including any internal DNS name.
- Metadata and discovery: confirm that the OIDC discovery document, or the SAML metadata where you use SAML, can be fetched from the cluster without outbound access. Plan how signing keys are rotated and distributed.
Before testing, ask the identity provider team to confirm in writing which metadata and key endpoints are reachable from the App Suite network segment.
What drives identity integration effort and how to keep it down
This table lists the inputs that change how much work an OX App Suite SSO and identity integration takes, and why. Each row names one driver, explains how it raises effort or cost, and gives one way to reduce it. Use it to prepare the inputs a partner needs for a fixed-scope quote.
| Driver | Why it raises effort or cost | How to keep it down |
|---|---|---|
| Identity providers and login paths | Each identity provider, such as an OpenID Connect or SAML source, needs its own trust setup, claim checks, error handling and test cases. Separate paths for staff, partners and customers multiply this work. | Limit the first release to one primary provider and one login path, then add others as separate, scoped changes. |
| Users and contexts to provision | Larger directories take longer to reconcile, and mismatched or duplicate accounts found during the first sync need manual review. Context structure affects how users are grouped. | Run a dry-run sync against a copy of the directory and agree on cleanup rules before cutover. |
| Attribute and group mapping complexity | Every mapped attribute, such as mail address, display name or group membership, needs a rule, a default and a test. Nested groups and multi-valued claims are the most common source of rework. | Document a short mapping table with one owner per attribute and remove attributes that no workflow uses. |
| Number of environments (test, staging, production) | Each environment needs its own identity provider registration, redirect URIs, secrets and provisioning credentials, and each must be kept in step with the others. | Keep environment differences in chart values only, and promote one tested configuration through each environment. |
| Custom login pages or branding | Custom login screens and branding change the sign-in flow, so they must be tested with every provider and browser the users rely on, and they must survive later releases. | Use the standard login page for the first release and schedule branding as a separate change after SSO is stable. |
| Compliance evidence for access control | Assessors often ask for proof of who can sign in, how access is removed and how sessions expire. Producing that evidence means logs, reviews and documented test results on top of the build. | Decide the evidence list before build starts so logging, retention and review steps are designed in, not added later. |
| Second environment to test failure paths | Testing provider outages, expired tokens, revoked users and session timeouts needs a separate environment where failures can be forced without affecting users. Skipping it moves these defects into production. | Reuse the staging environment with a scripted failure checklist, and ask the partner whether that scope is included in the quote. |
Provisioning users and contexts from your directory
The directory should decide who exists in OX App Suite, and the first design choice is how accounts reach the platform. With just-in-time creation, a user record is made the first time a person signs in through the identity provider. This keeps setup light, but a new hire has no working mailbox until the first login, and a leaver's record lingers until someone removes it. Scheduled synchronization pushes records from the directory on a timetable, so mailboxes and groups exist before anyone signs in, but it adds a job to run, monitor and reconcile when the two sides drift. Many teams combine them, using scheduled sync for create, update and disable and just-in-time creation as a fallback. Decide this before pilot users are loaded, because changing the model later means reconciling accounts that already own mail and files.
Attribute mapping is where directory data becomes mailbox behavior. Map the fields that identify a person, such as the immutable identifier, the primary mail address and the display name, and decide which system wins when they change. Quota and group membership are the settings most likely to be wrong on day one. Set quota from a policy the directory can express, such as a department or license attribute, so that manual edits in the admin console do not silently override it. Groups drive shared folders, distribution behavior and calendar access, so each directory group needs a named owner and a clear meaning. Ask Open-Xchange which attributes the target release reads from the identity provider, how it handles multi-valued attributes, and whether quota and groups can be driven from an external source. Write the mapping as a table and test it with a small pilot group before wider rollout.
Leavers are where orphaned mail and files appear. Disabling an account should stop sign-in while keeping the mailbox, calendar and Drive contents intact until a retention decision is made. Deleting the user too early can strand shared files, shared calendars and attachments that other people still reference. Define the offboarding sequence in writing: disable the account at the directory, revoke active sessions, reassign ownership of shared resources to a manager or service owner, archive the mailbox if policy requires it, and delete only after the retention window closes. Each step needs a named owner. Confirm with Open-Xchange how a disabled user is represented, whether files owned by that user stay accessible to others, and what deletion removes from the mail backend and from the distributed file or object storage. Those answers decide whether your offboarding runbook can be automated or must stay partly manual.
Session settings protect a disabled account only when they are set together. OX App Suite keeps its own session, and remember-me or autologin can keep a browser signed in after the identity provider has ended its session. If the identity provider session is long, the App Suite session is longer, and a remember-me token extends access further, a disabled user may keep working until every token expires. Align three values: the identity provider session lifetime, the App Suite session timeout and any remember-me or autologin duration. Shorter application sessions that re-authenticate silently through the identity provider cause a disabled account to fail at the next check. Test the case directly by disabling a pilot user and confirming that access stops in the web client, in mobile sync and in any client that reuses stored credentials. Record the exact values in the change record so later tuning keeps them aligned.
Securing SSO secrets, redirect URIs and sessions
Single sign-on for Open-Xchange puts a trust relationship between your identity provider and OX App Suite, and that relationship is only as strong as the secrets, redirect rules and session stores behind it. The controls below cover the points where an attacker could impersonate a user, replay a login or read a live session. Work through them together, since a gap in any one of them can undo the others.
Keep client secrets out of chart values
The OIDC client secret and any SAML signing or encryption certificates should be held in a secrets manager and injected into the OX App Suite deployment at runtime, not written into Helm values files stored in source control. Check the repository history as well as the current branch, because a secret committed once remains recoverable. Ask your platform team who can read the secrets store and whether rotation is documented for the identity provider and the OX side together.
Restrict redirect URIs to exact paths
Register each OX App Suite callback URL with the identity provider as an exact match, including scheme, host, port and path. Wildcard or prefix redirect patterns let an attacker steer an authorization code to a page they control. Review the registered list whenever a hostname changes during a migration or a new environment is added, and remove entries for environments that no longer exist.
Validate issuer, audience and signature
The middleware should accept an ID token only when the issuer matches the configured identity provider, the audience contains the registered client ID, and the signature verifies against the provider's published keys. Test with a token from a different client or a tampered payload to confirm rejection. Confirm with Open-Xchange which token validation settings the OIDC configuration exposes for your version, and record the expected values in your runbook.
Limit autologin to managed devices
Autologin shortens the login path and also widens the set of machines that can start a session without a fresh authentication. Enable it only for paths or device groups your security policy covers, such as enrolled endpoints, and keep the default login flow for everything else. Document which URLs and device classes allow autologin, and test that a request from an unmanaged browser still returns to the standard sign-in page.
Protect Redis session data
OX App Suite stores session and cache data in Redis, so anyone who can reach that instance can potentially read or replace sessions. Require authentication on the Redis connection, and use Kubernetes network policies so that only the OX App Suite workloads can open connections to it. Confirm with your Redis operator how credentials are generated and rotated, and whether TLS is available between the pods and Redis. Network-wide segmentation is covered in the hardening topic.
Log authentication events for review
Record successful and failed logins, token validation failures, redirect mismatches and autologin events, with timestamp, user, source address and client identifier. Forward these logs to a store your security team can search and retain them for a period set by your policy. Test the pipeline by generating a failed login and confirming it appears in the review tool within your agreed window.
How to test that Open-Xchange SSO works and fails safely
Before go-live, the single sign-on path for OX App Suite should be tested as a set of named cases, each with an expected result and recorded evidence. The core cases cover a successful login for every user group your directory defines, such as staff, contractors and shared-mailbox administrators, and a denied login for an account that has been disabled in the directory. Test both through the same entry point your users will use, whether that is the OpenID Connect flow or the SAML login configured for the middleware. Confirm which groups map to which OX roles and contexts, because a login that succeeds but lands in the wrong context is a failure even if the user reaches the mailbox.
Logout needs its own cases. Test logout from OX App Suite and confirm whether the identity provider session also ends, then test logout from the identity provider and confirm that OX App Suite no longer accepts the existing session. Check how these behave in each browser and mobile client your users rely on. Session expiry should be tested against the lifetime you configured, not an assumed default. Record the configured value, the time of login, the time of the forced expiry and the observed behavior, and include autologin rules if you have enabled them, since they can extend a session in ways that look like a defect.
Failure behavior matters as much as success. Make the identity provider unreachable in a test environment, for example by blocking its network path, and confirm that the fallback login path you have designed actually works for the users who need it. The test should also show that no account is locked out silently: users should receive a clear message, and administrators should see the failed attempts in logs. Clock skew tests should move the test client or the platform clock ahead and behind the identity provider and confirm that token validation errors appear where expected and that tokens expired by the provider are rejected. Confirm with your identity provider team the acceptable skew tolerance, because this value is set by your environment and not by OX App Suite.
Provisioning needs three tests: a create event that yields a working account in the correct context, a change event such as a department move or a renamed user that updates the attributes OX uses, and a leaver event that disables access and handles the mailbox and files according to your retention policy. Run each one against a test account and record the directory change, the provisioning job result and the resulting OX state. Ask the provisioning owner how failed jobs are retried and who is notified.
After go-live, monitor four signals: failed login rates, token validation errors, Redis session health and provisioning job results. A sudden rise in failed logins can indicate an identity provider certificate change or a clock problem, so set an alert threshold you agree with the identity team. Token validation errors deserve their own view because they separate configuration faults from user mistakes. Redis session health matters because sessions are stored there, so check memory, eviction and replication status. Keep a record of every test case with its ID, date, tester, environment, expected result, observed result and log or screenshot reference. This evidence supports internal audit and any compliance assessment you prepare for, although the auditor, not DeployOpen, decides whether the controls meet the standard.
Questions buyers ask about Open-Xchange SSO integration
What drives the cost and effort of an OX App Suite SSO integration?
The main drivers are the protocol, the number of identity providers, the provisioning model and the environments and evidence you need. Each one adds configuration, testing and review work. A single OpenID Connect provider with manual user creation is the smallest case. Several identity providers, SAML alongside OIDC, automated provisioning of users and contexts, and separate test, staging and production environments each add scope. Evidence needs, such as documented test results and change records for auditors, add effort too. Costs fall into two groups. Setup work is one-time: design, configuration, testing and cutover. Login policy changes, directory mapping updates and chart upgrades recur. When you request a quote, ask for the cost of each item separately, the assumptions behind it and which recurring tasks are included.
Can our own team set up OX App Suite SSO without outside help?
Yes, if your team has identity and Kubernetes skills and access to the official documentation for your release. The identity work needs someone who understands your identity provider's client registration, claims or attributes, session settings and logout behavior. The deployment side needs Kubernetes and Helm experience. OX App Suite v8 is delivered as Helm charts, and Helm 3.17.0 or newer is required, so confirm your tooling meets that version before you start. Teams without both skill sets often use a partner for the integration and keep operations in house afterward. Check the documentation for the exact release you run, because settings can differ between releases. A short internal pilot against a test identity provider will show you quickly whether the skills are there.
What does our team have to provide before SSO work starts?
The work needs five inputs from your side. First, administrator access to the identity provider, so client applications, redirect addresses and claim mappings can be created and tested. Second, named owners for directory attributes, since the login name, email address and group values must be agreed and stable. Third, test accounts that cover normal users, administrators and any edge cases such as locked or disabled accounts. Fourth, a change window for the cutover and a rollback plan. Fifth, a named approver for login policy, covering session lifetime, autologin rules and logout behavior. Without these, schedules slip because decisions wait on people who are not in the project. Confirm each name and availability in the written scope before the work begins.
How does a partner scope SSO work and what is agreed in writing?
Most DeployOpen engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing. For SSO, the scope usually names the protocol and identity providers in use, the provisioning approach, the environments covered, the testing to be performed and the documentation delivered. The quote follows from that written scope rather than from a published price list, which DeployOpen does not publish. Ask the partner to show which items are included, which depend on your inputs and which are excluded, such as ongoing support or later changes to login policy. Ongoing support, upgrades and continuous testing are available as separate retainers. A clear written scope makes it easier to compare proposals from different partners on the same basis.
Does SSO for OX App Suite depend on the license terms?
It can. Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before you design the integration, confirm with Open-Xchange which login features, identity connectors and provisioning functions your agreement covers. Do not assume that every login option in the documentation is included for your deployment. The publicly available source code does not replace the terms of your agreement. Ask your Open-Xchange contact to confirm coverage in writing, and record the answer in the project scope. If a feature you need is restricted, decide early whether to change the design, obtain a license change or accept a different approach, because that decision affects cost and timing.
Should we choose OpenID Connect or SAML for OX App Suite?
OpenID Connect is the protocol Open-Xchange documents for OX App Suite single sign-on, so it is the usual starting point. Open-Xchange also documents SAML login configuration for the middleware in its operator guide. That SAML guide is published under a 7.10.1 path, so confirm with Open-Xchange and your release notes that the steps apply to your v8 deployment before you rely on them. Choose based on what your identity provider supports well, how your organization already manages applications and which claims you need for user and context mapping. If you run both protocols for different user groups, the design, testing and login policy work roughly doubles for those groups. Document the decision, the reasons and the owner, since it affects provisioning and audits later.
What usually goes wrong in an OX App Suite SSO integration?
Several problems appear often enough to test for on purpose. Redirect addresses in the identity provider do not match the public address of the deployment, so logins fail after the provider returns the user. Attribute mappings are wrong, so the login name or email address differs from the one already stored, which can create duplicate or unreachable accounts. Session lifetime in OX App Suite and session lifetime at the identity provider disagree, so users are logged out at unexpected times. Autologin rules conflict with logout, leaving users signed in on shared machines. Group or role values change in the directory without anyone updating the mapping. Testing should cover each of these cases with the test accounts you provide, and the results should be recorded before the change window.
How DeployOpen scopes, builds and hands over SSO work
DeployOpen approaches Open-Xchange SSO and identity integration as part of a self-hosted OX App Suite deployment inside your own infrastructure. OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware, so the protocol choice is made early and recorded. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope that names the identity protocol, OpenID Connect or SAML, before any configuration starts
- Session lifetime and autologin rules agreed with your security team and recorded in the scope document
- Directory source, user and context provisioning fields, and which attributes map to OX accounts
How we build
- Configure OpenID Connect login against your identity provider in the OX App Suite v8 deployment
- Where SAML is chosen, configure middleware login settings and test assertions in a non-production environment first
- Provisioning and autologin rules tested with sample users, expired sessions and logout paths
How we hand over
- Written configuration record covering identity settings, session rules, provisioning jobs and Helm values per environment
- Test evidence for each login path, logout behavior and provisioning run, kept with the handover pack
- Walkthrough with administrators on rotating identity provider secrets and changing session lifetimes safely
How we support
- Ongoing support and upgrades available as a retainer, covering identity changes after go-live
- Re-test SSO and provisioning when moving between OX App Suite releases within the support window
- Identity provider changes handled through a documented change process agreed in the support scope
