JumpCloud SSO and MFA for Oracle PeopleSoft with Datawiza

Your organization uses JumpCloud to manage identity and secure access to applications. But Oracle PeopleSoft still has its own sign-in experience. Employees move between modern SSO-enabled services and a separate login for HR, payroll, or finance—and IT has another authentication flow to manage.

Datawiza Access Proxy connects JumpCloud SSO and MFA to Oracle PeopleSoft. JumpCloud authenticates users and applies the configured MFA policy. Datawiza handles the identity integration and access checks in front of PeopleSoft, while PeopleSoft retains its application permissions. Explore Datawiza's PeopleSoft SSO and MFA solution.

The goal is straightforward: extend the identity platform you already use to PeopleSoft without building a new federation layer inside the application.

Why connect JumpCloud to PeopleSoft through an access proxy?

PeopleSoft authentication and modern identity-provider federation are different integration problems. Having a JumpCloud account does not, by itself, establish a PeopleSoft session or grant access to payroll records.

An access proxy bridges that gap. Instead of asking PeopleSoft to act as the modern federation endpoint, you connect JumpCloud to Datawiza and configure a trusted identity handoff to PeopleSoft. For the wider architecture, see our PeopleSoft SSO implementation guide.

This separates three responsibilities:

• JumpCloud: verify the user's identity and apply the required authentication policy.
• Datawiza: validate the sign-in result or existing session, enforce configured access rules, and pass the mapped identity to PeopleSoft.
• PeopleSoft: recognize the application user and enforce roles, permission lists, and business-level authorization.

It also keeps the project focused. You do not need to introduce Oracle Access Manager or Oracle Identity Cloud Service solely to establish this Datawiza integration. Existing Oracle identity infrastructure can still be part of your broader environment.

How JumpCloud SSO and MFA for PeopleSoft works

Conceptual architecture: JumpCloud handles authentication; application requests pass through Datawiza to PeopleSoft. The upper connection represents the identity integration, not a packet-by-packet protocol flow.

1. A user opens the protected PeopleSoft URL.
2. If authentication is required, Datawiza initiates the configured JumpCloud sign-in flow.
3. JumpCloud evaluates the applicable policy and requires MFA when that policy calls for it.
4. Datawiza validates the authentication result, applies its access policy, and maps the identity for PeopleSoft.
5. PeopleSoft establishes the appropriate application session and applies that user's permissions.

An existing valid session may avoid another sign-in prompt. SSO does not mean a new MFA challenge on every page request, nor does it automatically mean that all three systems share one session lifetime.

Plan your JumpCloud–PeopleSoft integration

This is an implementation-planning guide, not a version-specific configuration recipe. Confirm the connector settings and PeopleSoft changes for your environment with Datawiza before production rollout.

1. Define the PeopleSoft environment and pilot users

Start with one nonproduction environment and a small representative group. Record the PeopleTools version, public URL, backend addresses, load balancer, certificates, and authentication settings. Include deep links used for approvals and self-service—not just the home page.

Inventory browser access separately from Integration Broker services, scheduled jobs, APIs, and administrative tools. A browser SSO flow should not be assumed to cover every PeopleSoft-related connection.

Assign owners for JumpCloud, Datawiza, and PeopleSoft configuration. Agree on a rollback plan before changing production routing.

2. Configure the federation connection

JumpCloud provides custom SAML application connectors and custom OIDC connectors. Datawiza documents Generic SAML and Generic OIDC configuration; choose the protocol and configuration supported by your deployment.

The federation endpoint is Datawiza, not PeopleSoft itself. For SAML, exchange the relevant service-provider and identity-provider metadata and configure the expected user identifier. For OIDC, use the required redirect URI, client ID and, where required, client secret, plus the correct issuer settings and claims.

Use the values supplied by your actual Datawiza configuration. Do not substitute a PeopleSoft home-page URL for a callback or copy another provider's settings unchanged. Limit initial application assignment to the pilot users or groups.

3. Require JumpCloud MFA for the application

SSO and MFA are separate controls. A successful federation setup is not proof that MFA is required.

Configure the appropriate JumpCloud policy for the SSO application, and verify its scope, exceptions, and fallback behavior. JumpCloud distinguishes policies for the User Portal from policies for SSO applications; test access that starts directly at the protected PeopleSoft URL, not only from the portal. See JumpCloud's conditional access documentation.

JumpCloud documents methods including JumpCloud Protect push and WebAuthn security keys or device authenticators. Select methods supported for the relevant resource and user devices, and verify enrollment and recovery before rollout. Advanced conditions and authentication methods can have subscription, browser, or device requirements. Consult the JumpCloud MFA administrator guide.

For this integration, JumpCloud supplies MFA. Datawiza's separate built-in MFA option is not an additional requirement.

4. Map JumpCloud users to PeopleSoft accounts

Decide which verified JumpCloud attribute corresponds to each PeopleSoft user ID. An email address, directory username, and PeopleSoft account name are not necessarily interchangeable.

For example, a JumpCloud email might be alex.chen@example.com, while the existing PeopleSoft ID is ACHEN. Define and test an explicit mapping instead of assuming those values match. Include case sensitivity, missing attributes, renamed users, and duplicate values in your tests.

Datawiza's published PeopleSoft integration uses the PSSSOUID header for the identity handoff. Its PeopleSoft configuration guide illustrates the application-side setup using Okta; the JumpCloud federation configuration must be established separately.

Keep PeopleSoft user provisioning and permissions under deliberate administration. Signing in through JumpCloud does not automatically create a PeopleSoft account, synchronize all roles, or grant transaction-level privileges. Oracle's web-server authentication flow explains how the external user ID establishes the PeopleSoft session.

5. Complete the PeopleSoft-side setup

Datawiza handles modern federation outside PeopleSoft, but that does not mean the application needs no configuration.

Depending on your deployment, the work can include web-profile settings, Signon PeopleCode configuration, the trusted user header, public-facing addressing, and login/logout/timeout handling. The published Datawiza guide includes changes to these areas. Review the applicable steps with your PeopleSoft administrator rather than treating the integration as a universal zero-change installation.

The practical benefit is avoiding a from-scratch SAML or OIDC implementation inside PeopleSoft—not eliminating configuration, testing, or change control.

6. Protect the proxy-to-PeopleSoft trust boundary

For protected endpoints, restrict the backend so users cannot reach it through an alternate hostname, direct IP address, or port that bypasses Datawiza. Changing DNS alone does not close those routes.

A trusted identity header must come from the trusted integration, not from a value an outside caller can supply. Test the treatment of incoming identity headers and the network restrictions together. Datawiza's network-restriction guidance explains the origin-access boundary.

Use HTTPS, protect connector credentials, maintain the proxy, and plan availability. Continue patching PeopleSoft and its supporting infrastructure: MFA and access policies do not repair vulnerable code. For the wider model, see zero trust application security.

7. Validate the complete user journey

Before rollout, verify:

• Successful access: the correct user reaches the intended PeopleSoft page after the required authentication.
• Denied access: unassigned users, failed MFA, and invalid identity mappings cannot reach protected functionality.
• Session behavior: idle timeout, logout, fresh-browser login, and existing sessions behave as intended.
• Offboarding: disabling or unassigning a user produces the expected result, including for already-open sessions.
• Application workflows: approvals, deep links, downloads, and separate nonbrowser integrations still work as designed.
• Operations: the team can investigate failures, recover from an outage, and execute the approved rollback.

Do not assume that logging out of PeopleSoft also ends every JumpCloud session, or that disabling an account instantly invalidates all application sessions. Verify the configured behavior and document the limits.

What your team gains

The strongest outcome is a consistent access experience with clear ownership. Employees use JumpCloud for authentication, IT manages the applicable sign-in policy there, and PeopleSoft continues to control what users can do inside the application.

Datawiza adds an application-access enforcement point between the browser and PeopleSoft. Its access rules can use paths, HTTP methods, and available identity or request attributes. Those rules complement—not replace—PeopleSoft permissions.

This is particularly useful when your identity program is already centered on JumpCloud and PeopleSoft remains an exception. Modernize that access path while preserving the application's business workflows.

FAQ

Can JumpCloud provide SSO and MFA for Oracle PeopleSoft?

Yes. With Datawiza Access Proxy as the integration layer, JumpCloud can handle sign-in and MFA for the protected PeopleSoft browser access flow. Configure and validate federation, user mapping, application-side trust, and access policies for your environment.

Does this require Microsoft Entra ID, Active Directory, or LDAP?

The federation path described here uses JumpCloud as the identity provider; it does not require adding Entra ID, AD, or LDAP just to connect JumpCloud to Datawiza. Existing directory dependencies elsewhere in your organization are a separate consideration.

Can users keep their PeopleSoft roles?

Yes. Map each authenticated identity to the intended PeopleSoft account and retain the required application permissions. SSO does not automatically provision accounts or replace PeopleSoft role administration.

Do we need to replace PeopleSoft or implement MFA inside it?

No. JumpCloud supplies MFA and Datawiza connects the identity flow to PeopleSoft. Application-side setup may still be needed, including trusted-header, sign-on, and session configuration. Review the requirements for your PeopleTools version.

Bring JumpCloud SSO and MFA to PeopleSoft

If JumpCloud already manages your workforce identities, PeopleSoft does not need to remain a separate authentication project. Start with a scoped pilot and prove the identity mapping, MFA enforcement, and user experience before expanding.

Book a 30-minute Datawiza demo to review your JumpCloud environment and plan PeopleSoft SSO and MFA.