Per una grande organizzazione, l’identità non è più un confine definito ma un ecosistema frammentato. Operare in scenari ibridi e multi-cloud significa oggi gestire identità distribuite su più foreste AD/LDAP, sistemi HRIS (Workday, SAP), ecosistemi SaaS e applicazioni custom/on-premise. Questa stratificazione non è solo un onere amministrativo, ma una vulnerabilità operativa che genera criticità tecniche ricorrenti e spesso sottovalutate:
- L’abisso dei protocolli: La coesistenza di standard moderni (OAuth 2.0, SAML2.0) e sistemi legacy (WS-Fed, Kerberos) impone una token mediation
- Routing e Contesto: La necessità di un Home Realm Discovery (HRD) intelligente che non si limiti al dominio, ma governi i flussi in base a location, posture e risk score.
- Gestione delle sessioni, step‑up MFA e state condiviso in HA.
- Disallineamento del Ciclo di Vita: La sfida di sincronizzare attributi e ruoli tramite SCIM o logiche event-driven, garantendo che il provisioning/de-provisioning sia immediato.
- Accesso a sistemi legacy (header‑based) e app senza supporto nativo per SAML/OIDC.
- Governance Frammentata: L’assenza di policy ABAC/RBAC centralizzate che rendono l’audit e la conformità un processo manuale e propenso all’errore.
Come possiamo gestire queste criticità?
Gli Strati Invisibili della Federazione delle Identità
Centralizzare l’autenticazione significa portare ordine in un ecosistema frammentato, convogliando ogni richiesta di accesso verso un’unica regia. In pratica, questo avviene attraverso una piattaforma di federazione delle identità, che diventa il punto in cui si decide chi è l’utente, come deve autenticarsi e quali credenziali o token gli vengono rilasciati.
Per comprendere come gli strumenti IAM si comportino in un contesto reale, consideriamo due scenari emblematici nei quali la federazione, l’orchestrazione dell’autenticazione e la gestione dei token vengono applicate in modo concreto:
Scenario 1 — SSO ibrido per workforce
In un ambiente con utenti dislocati su più foreste Active Directory, applicazioni SaaS come M365 e sistemi interni che espongono interfacce SAML o OIDC, il primo passaggio è sempre il discovery. Un accesso SP‑initiated verso un servizio cloud redirige l’utente all’IdP centrale, che funge da issuer unificato.
Da qui parte la vera e propria catena autenticativa. Se l’utente si trova in intranet e utilizza un dispositivo trusted, l’accesso può essere trasparente. In condizioni diverse, entra in gioco una catena più moderna: WebAuthn/FIDO2 o certificati (CBA), con fallback su password + MFA. Le policy possono innescare uno step‑up obbligatorio quando il rischio è elevato (valutato tramite segnali comportamentali o contestuali) o quando si accede a risorse classificate come high value.
Una volta autenticato, il sistema procede con l’attribute aggregation, combinando in tempo reale attributi provenienti da AD/LDAP, HRIS e sorgenti REST. Questa fase è essenziale per costruire un profilo coerente che includa dipartimento, manager, country e entitlements. Gli attributi alimentano poi l’issuance del token.
La sessione, una volta stabilita, può essere riutilizzata su applicazioni SaaS e sistemi interni sia OIDC che SAML tramite mapping inter‑protocollo e session cookie dell’IdP. Parallelamente, il provisioning avviene via SCIM: gruppi e ruoli vengono sincronizzati sull’app target, mentre eventuali terminazioni lato HR attivano automaticamente il de‑provisioning.
Il risultato è un modello di accesso coerente su tutto il perimetro aziendale: policy MFA centralizzate, attributi uniformi, crittografia dei token ottimizzata per RP differenti e un dominio di trust finalmente unificato.
Scenario 2 — Modernizzazione di applicazioni legacy non federate
Il secondo scenario riguarda applicazioni interne che non supportano SAML o OIDC e richiedono invece header HTTP o ticket Kerberos. Qui il punto di ingresso è l’Access Gateway, che intercetta la richiesta dell’utente prima che raggiunga l’applicazione.
Il Gateway redirige l’utente verso l’IdP per l’autenticazione, utilizzando la stessa catena policy‑driven vista nello scenario precedente. L’IdP emette poi un token che il Gateway valida verificandone la firma e recuperandone gli attributi. A questo punto vengono eseguite le trasformazioni necessarie per adeguarsi al backend. Ad Esempio, nei contesti Windows è possibile utilizzare anche la Kerberos Constrained Delegation per ottenere un SSO end‑to‑end senza modificare il codice applicativo.
Il Gateway, agendo come PEP, applica policy ABAC basate su attributi e contesto (es. country=EU, risk<medium, device=managed), bloccando l’accesso o richiedendo step‑up in tempo reale se le condizioni non sono soddisfatte.
Come Ping Identity implementa la Federazione Enterprise
La risoluzione pratica delle complessità legate a SSO, federazione e modernizzazione degli accessi passa da un insieme di componenti specializzate, ciascuna progettata per affrontare un tratto preciso della catena IAM. Ping Identity propone un’architettura modulare, in cui ogni elemento fornisce capability specifiche ma integrate in un disegno coerente.
PingFederate opera come IdP e SP proxy, fungendo da vero protocol hub capace di mediare tra sistemi eterogenei. Attraverso il bridging fra SAML, OIDC e WSFed, la piattaforma consente di standardizzare i flussi di autenticazione indipendentemente dal formato utilizzato dall’applicazione a monte o a valle.
L’emissione dei token è supportata da un motore avanzato di attribute sources & contracts, che aggrega attributi da directory, HRIS e API REST, normalizzandoli prima del rilascio dell’asserzione. La piattaforma supporta sia sessioni stateless JWT sia modelli stateful con cluster runtime e nodo amministrativo dedicato per garantire alta disponibilità.‑Fed, la piattaforma consente di standardizzare i flussi di autenticazione indipendentemente dal formato utilizzato dall’applicazione a monte o a valle.
PingAccess agisce come Access Gateway e Policy Enforcement Point, proteggendo applicazioni web e API tramite validazione JWT/SAML e header injection per i sistemi non nativamente federati.
Le policy possono essere definite per percorso, metodo, claim e contesto, mentre l’integrazione diretta con PingFederate permette di usarlo come Policy Decision Point centralizzato.
Ci sono poi le componenti cloud che introducono un insieme di funzionalità dedicate a MFA e risk engine. PingID/PingOne MFA supporta TOTP, push, FIDO2/WebAuthn e certificati (CBA), mentre PingOne Protect valuta geovelocity, IP reputation e device posture per attivare automaticamente lo step‑up.
L’orchestrazione dei flussi è affidata a DaVinci, una piattaforma no‑code che consente branching, enrichment e integrazione via webhook, facilitando l’evoluzione del modello di autenticazione.
Sul fronte del lifecycle, PingOne gestisce sincronizzazione, push e allineamento utenti/ruoli, con possibilità di utilizzare una directory cloud dedicata.
Infine, PingAuthorize calcola decisioni di accesso basate su attributi relativi a utente, risorsa e contesto ambientale. Il motore consente enforcement fine‑grained su API e applicazioni web, fornendo l’elemento abilitante del modello Zero Trust.
Conclusioni
Non lasciamoci ingannare: centralizzare l’autenticazione non è un esercizio di stile per architetti IT, è una necessità di business. Una multinazionale che non domina i propri flussi di identità è un’azienda che non può scalare, che fallisce gli audit di conformità e che resta vulnerabile ad attacchi di tipo identity-first.
L’approccio modulare di Ping Identity non offre solo una “scatola” di attrezzi, ma abilita quello che oggi definiamo Identity Fabric: un’infrastruttura capace di estendere la fiducia anche ai sistemi più datati, di prendere decisioni in tempo reale e di eliminare la password come punto debole. Il passaggio a questo modello non è privo di sfide implementative, ma è l’unico percorso per chi vuole trasformare l’identità da un insieme di credenziali distribuite ad un asset strategico pronto per il futuro Zero Trust.
Consulta la nostra pagina: https://bludis.it/prodotto/ping-identity/ e contattaci per maggiori informazioni. Invia una e-mail a marketing@bludis.it
