Identity Adapters

Overview

PDAccess authenticates users against the identity sources you already run. An identity adapter binds an external directory or authentication server to PDAccess, maps its groups to PDAccess roles, and provisions users just-in-time — no local user store, no duplicate accounts.

Every proxy session begins with an adapter authentication. The adapter is the first gate in the policy chain, and it fails closed: a down adapter denies access, it never bypasses.

LDAP

The LDAP adapter integrates directory services for authentication and group-based authorization.

• Protocol: LDAPv3 (RFC 4511); Active Directory and OpenLDAP
• Transport: LDAPS (TCP 636) or StartTLS over port 389
• Bind model: PDAccess binds with a service account, then verifies the user by performing a user bind — the user's password is checked against the directory and is never stored in PDAccess
• Group mapping: group membership (memberOf in Active Directory, or group-DN search in OpenLDAP) maps to PDAccess roles through filter rules
• Attribute sync: display name, email, and department sync from the directory on each authentication
• MFA layering: an MFA policy attaches to the adapter, on top of the directory password check

RADIUS

The RADIUS adapter integrates RADIUS servers for network-centric authentication and session accounting.

• Protocol: RADIUS (RFC 2865/2866) over UDP 1812 (auth) / 1813 (accounting)
• Shared secret: a per-adapter shared secret secures the exchange between PDAccess and the RADIUS server
• Attributes: Reply-Message, State, and NAS-identifier attributes are honored; session attributes can be mapped into policy context
• CoA: Change of Authorization (RFC 5176) — PDAccess can push CoA to the RADIUS backend to terminate an active session on policy violation
• Accounting: session start/stop accounting records are written to the PDAccess audit trail
• EAP pass-through: EAP methods (EAP-TLS, PEAP) pass through to the RADIUS server for client-certificate authentication

TACACS+

The TACACS+ adapter integrates Cisco TACACS+ infrastructure and preserves the separated AAA model.

• Protocol: TACACS+ (RFC 896) over TCP 49
• Separated AAA: authentication, authorization, and accounting are separate exchanges — PDAccess uses each independently
• Per-command authorization: the adapter queries TACACS+ for command authorization on network devices, so a policy can permit show and prompt-approve configure
• Packet encryption: TACACS+ payload encryption with the shared secret; the authentication exchange uses MD5-hashed passwords
• Session accounting: per-command accounting from the device is correlated with the PDAccess session record

OAuth 2.0 / OpenID Connect

The OAuth 2.0 / OIDC adapter integrates modern identity providers for single sign-on.

• Standards: OAuth 2.0 (RFC 6749), OpenID Connect Core 1.0 (RFC 8363), JWT (RFC 7519)
• Flow: authorization code flow with PKCE — the user is redirected to the IdP, authenticates (including the IdP's MFA), and returns with an ID token
• Token validation: ID tokens are validated against the IdP's JWKS signing keys; issuer, audience, expiry, and nonce are all checked
• Supported IdPs: Microsoft Entra ID (Azure AD), Okta, Google Workspace, Auth0, and any standards-compliant OIDC provider
• Claim mapping: sub, name, email, and group claims (groups / roles) map to PDAccess users and roles
• Just-in-time provisioning: a user who has not seen PDAccess is provisioned on first successful authentication, with roles derived from group claims
• Session binding: the IdP session lifetime bounds the PDAccess session; RP-Initiated Logout at the IdP closes the PDAccess session

Group Mapping and Roles

Each adapter defines mapping rules from its groups to PDAccess roles:

Rules are evaluated in order; the highest-precedence match wins. MFA requirements attach to the adapter, so a break-glass adapter can demand hardware-key MFA while a standard AD adapter accepts the IdP's MFA state.

Multiple Adapters and Failover

• Multiple adapters can be configured simultaneously; each user authenticates through the adapter assigned to their access policy
• Adapters are health-checked; a down adapter fails closed — sessions through it are denied, not bypassed
• Break-glass paths use a dedicated adapter with its own MFA and dual-approval policies