Insufficient Logging in Actix with Saml

Insufficient logging in an Actix web service that uses SAML for authentication creates blind spots in security visibility. When SAML-based authentication flows are not fully recorded, incidents such as invalid assertions, unexpected identity provider (IdP) responses, or missing attributes are not detectable in real time. This lack of visibility is especially risky because SAML relies on redirects and signed assertions, which can be abused if anomalies are not captured and reviewed.

Without structured logs for SAML events like AuthnRequest issuance, Response validation success/failure, NameID binding, and session state changes, an attacker can manipulate assertions or replay responses with limited risk of detection. For example, an IdP returning a missing or malformed Subject or an unset SessionIndex may indicate a federation misconfiguration or a tampered response, but without logs these issues remain invisible. Actix applications that do not log key SAML inputs (e.g., SAMLResponse and SAMLRequest) and outcomes (validation results, user identity, session creation) fail to support forensic analysis and incident response.

Additionally, insufficient logging of authorization decisions tied to SAML attributes can lead to privilege escalation or access to unauthorized endpoints. If role or group claims are not logged alongside the authenticated identity, it becomes difficult to verify whether access controls are being applied correctly. This is compounded when Actix relies on middleware that processes SAML assertions but does not emit structured logs for each check, making it hard to correlate authentication events with downstream API or resource access.

To address insufficient logging in Actix with SAML, instrument every critical step of the SAML flow with structured, contextual logs. Ensure logs include timestamps, request IDs, entity IDs, and outcome status without recording sensitive assertion content. Below are concrete examples using the actix-web framework and the saml2 Rust crate.

1. Logging SAML requests and responses

Log incoming SAMLResponse and SAMLRequest values at a safe abstraction level. Record metadata, not raw assertions.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use saml2::protocol::Response;
use serde_json::json;

async fn handle_saml_response(
    req: HttpRequest,
    form: web::Form>,
) -> Result {
    let request_id = uuid::Uuid::new_v4().to_string();
    let saml_response = form.get("SAMLResponse").map(|v| v.as_str());
    let relay_state = form.get("RelayState").map(|v| v.as_str());

    // Log metadata for observability
    web::block(move || {
        info!(target: "saml", request_id = %request_id, event = "SAMLResponseReceived",
            method = req.method().as_str(), path = req.path(),
            relay_state = relay_state,
            saml_response_present = saml_response.is_some(),
            saml_response_len = saml_response.map(|v| v.len()).unwrap_or(0),
        );
    }).await.map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    // Continue parsing and validating the SAML response
    // ...
    Ok(HttpResponse::Ok().finish())
}

2. Logging validation outcomes

Log the result of signature and condition checks, including issuer and NameID details at a safe granularity.

use saml2::config::Metadata;
use log::info;

async fn validate_saml_response(response: &Response) -> bool {
    let metadata = Metadata::from_reader(include_bytes!("idp-metadata.xml"));
    match response.validate(&metadata) {
        Ok(claims) => {
            info!(target: "saml", event = "SAMLValidationSuccess",
                issuer = %claims.issuer().to_string(),
                nameid = %claims.name_id().to_string(),
                session_index = %claims.session_index().unwrap_or("none"),
            );
            true
        }
        Err(err) => {
            info!(target: "saml", event = "SAMLValidationError", error = %err.to_string());
            false
        }
    }
}

3. Logging attribute mapping and authorization context

Log the mapping of SAML attributes to local roles and the decisions made, enabling traceability for access reviews.

use log::warn;

fn map_attributes_to_roles(attributes: &HashMap>) -> Vec {
    let roles = attributes.get("Role").cloned().unwrap_or_default();
    if roles.is_empty() {
        warn!(target: "saml", event = "MissingRoleAttribute",
            available_attributes = ?attributes.keys().collect::>(),
        );
    }
    roles
}

4. Correlation and replay protection logging

Log InResponseTo and IssueInstant to help detect replay attempts and out-of-order responses.

use saml2::protocol::Response;

fn log_response_context(response: &Response) {
    if let Some(in_response_to) = response.in_response_to() {
        info!(target: "saml", event = "SAMLResponseCorrelation",
            in_response_to = %in_response_to,
            issue_instant = %response.issue_instant().to_string(),
        );
    }
}