feat(server): add CredentialValidator trait for server-side auth

[Greg Lamberson (glamberson)]

Closes #1154

Summary

Add a CredentialValidator trait that lets servers validate client
credentials during connection setup, after the acceptor extracts them
from ClientInfoPdu (enabled by #1155).

This follows up on the API discussion in #1150: Option<Credentials>
is the wrong type to carry security policy. The trait makes auth an
explicit, application-supplied component rather than an implicit
builder default.

What it does

• CredentialValidator trait with validate(&self, &Credentials) -> Result<CredentialDecision, CredentialValidationError>.
• CredentialDecision::{Accept, Reject} enum for the binary outcome (no stringly typed bool).
• CredentialValidationError wrapping any core::error::Error + Send + Sync for backend-failure cases (LDAP/PAM/DB unreachable). Manual Display + core::error::Error impls; the source chain is preserved through .source().
• RdpServerBuilder::with_credential_validator(Option<Arc<dyn CredentialValidator>>) to wire it in at construction time, matching the with_* pattern of every other configurable on BuilderDone.
• RdpServer::set_credential_validator(Option<Arc<dyn CredentialValidator>>) for post-construction reconfiguration.
• Validation runs in client_accepted() before session start.
• No validator configured = no credential check (existing behavior).
• Validator configured + credentials received = validate, reject on Decision::Reject or backend Err(_).
• Validator configured + no credentials received = skip validation (covers CredSSP/Hybrid path and reactivation/resize iterations where AcceptorResult.credentials is None per fix(acceptor): skip credential check when server credentials are None #1150/feat(acceptor): expose received client credentials in AcceptorResult #1155).

Design

For TLS-only connections, Client Info credentials are the only
credentials the application layer receives (no CredSSP). This trait
gives server implementations a clean hook to validate them against
PAM, LDAP, databases, or any external system.

Not used for CredSSP/Hybrid connections, where authentication happens
during the NTLM challenge-response exchange before ClientInfoPdu.

Rejection is modelled as Ok(CredentialDecision::Reject), not as an
Err. A rejection from a working validator is the validator doing
its job, not a failure of the validator itself. Only true backend
infrastructure failures (the LDAP server is down, the PAM transport
broke) return Err(CredentialValidationError::new(_)). This keeps
the three outcomes (accept / reject / infrastructure-error) distinct
at every call site.

Hand-rolled Display + core::error::Error impls follow the
post-#1264 workspace pattern; no thiserror, no anyhow leakage
across the public trait boundary.

Example

use std::sync::Arc;
use ironrdp_server::{
    CredentialDecision, CredentialValidationError, CredentialValidator, Credentials,
    RdpServer,
};

struct PamValidator;

impl CredentialValidator for PamValidator {
    fn validate(
        &self,
        creds: &Credentials,
    ) -> Result<CredentialDecision, CredentialValidationError> {
        match pam_authenticate(&creds.username, &creds.password) {
            Ok(true) => Ok(CredentialDecision::Accept),
            Ok(false) => Ok(CredentialDecision::Reject),
            Err(backend_err) => Err(CredentialValidationError::new(backend_err)),
        }
    }
}

let server = RdpServer::builder()
    .with_addr(addr)
    .with_tls(acceptor)
    .with_input_handler(my_input)
    .with_display_handler(my_display)
    .with_credential_validator(Some(Arc::new(PamValidator)))
    .build();

Tests

Public-API tests for the trait, CredentialDecision, and the error
wrapper's source-chain propagation live in
crates/ironrdp-testsuite-core/tests/server/credential_validator.rs,
matching the canonical IronRDP split (public-API tests in
ironrdp-testsuite-core, inline #[cfg(test)] for crate-internal
behavior, per the existing autodetect.rs precedent).

Test plan

cargo xtask check fmt/lints/tests/typos/locks all pass.

[Copilot]

Pull request overview

Adds a server-side hook to validate client-supplied credentials (from ClientInfoPdu) during connection setup, enabling external authentication backends (PAM/LDAP/DB) in ironrdp-server.

Changes:

• Introduces a new public CredentialValidator trait.
• Adds an optional validator to RdpServer with a setter API.
• Invokes credential validation in client_accepted before entering the session loop.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Greg Lamberson (glamberson)]

Rebased. Thanks.

[Greg Lamberson (glamberson)]

Benoît Cortier (@CBenoit) Hi, I hope you can consider this with some priority as it's a feature I require in both lamco-rdp-server and lamco-qemu-rdp (Proxmox RDP Server component) and currently resides in a fork which I'd like to eliminate.

Thanks!

[Greg Lamberson (glamberson)]

Benoît Cortier (@CBenoit) Hi, could you please review this and merge it ASAP? This one is a real bottleneck for me. Do you have any issues or concerns you'd like me to address or any issues with merging otherwise? Please let me know if so. Thanks.

[Greg Lamberson (glamberson)]

Benoît Cortier (@CBenoit) Today is 2026-05-25. PR #1172 has been open since 2026-03-17, which is 70 days. CI is green across all 20 checks on the current head (1f8d5014, just rebased onto master 879ffed8). All 5 Copilot review threads from the 2026-03-18 pass are resolved. There has never been a maintainer review on this PR; the only review history is Copilot's. I have rebased four times and pushed two substantive reshapes, including the 2026-05-20 typed-error refactor that moved the API from anyhow-leaking Result<bool> to CredentialDecision::{Accept, Reject} plus a CredentialValidationError wrapper with manual Display + core::error::Error impls, and the migration of public-API tests into ironrdp-testsuite-core/tests/server/credential_validator.rs per the autodetect.rs precedent.

I have pinged twice (2026-05-16, 2026-05-20). Both pings explicitly invited "what do you want me to change" feedback. Neither got a response. In the same five-day window since the 2026-05-20 ping, you have merged eight of my other PRs, including a Saturday-filed one (#1303) that landed Monday morning. The signal is that this specific PR is being deferred, not lost in queue.

I respect that Devolutions has priorities I do not see and competing directions I am not party to. Those are legitimate. I have tried to bend over backwards to align my work with what I understand about your priorities: the precheck-driven amend cadence, the testsuite-core test-placement convention, the typed-error-no-anyhow direction, the conventional-commit + BREAKING CHANGE: discipline for release-plz, the with_* builder convention, the spec-MUST-on-emit + liberal-on-receive posture you've prescribed elsewhere. I would appreciate some attention to mine here. lamco-rdp-server and the planned lamco-qemu-rdp (Proxmox RDP server component) both have a hard dependency on a server-side credential-validation hook. I have been carrying that hook on feat/lamco-combined in our fork for 70 days. Every release I cut from that branch is a fork-rebase exercise I would prefer not to do indefinitely.

What I want is engagement, not approval. The options I see, from my side:

1. The trait is fine but you want a different shape. Tell me which shape (different signature, different placement on ConnectionHandler instead of standalone, different name, dropped builder method, different lifecycle hook, anything) and I will rework. I have explicit cycles available this week.
2. You do not want this surface upstream at all (Devolutions has plans for credential validation that conflict, the trait surface is wrong for IronRDP's API direction, or any other reason). Tell me and I will close the PR with a documenting comment and carry the patch downstream permanently. No friction.
3. You want the discussion but the shape needs broader maintainer input first. Tell me and I will wait, with a known target date or a known trigger event.

Competing priorities, conflicting thoughts, structural concerns, scope disagreements: all of these are fine and I welcome the discussion. Silence is what is not working here. What is the path forward?