Sto facendo esperimenti con Kerberos e mi stavo chiedendo se fosse una specie di l'autenticazione composita che identifica sia un utente che l'origine della richiesta degli utenti è stata a) possibile eb) implementata ovunque.
Quello che sto cercando è un setup in cui c'è un intermedio entità (potrebbe essere la macchina degli utenti, potrebbe essere il router il client si sta connettendo attraverso) che altera i messaggi di un cliente a un Authentication Server (AS) in modo che identificano sia l'utente che l'origine della richiesta. L'AS può quindi tenere conto di questa modifica e inviare un TGT che può essere utilizzato per concedere l'accesso in base alla fonte.
Questo potrebbe essere usato, per esempio, se tu avessi un terminale di computer al bancone di un negozio e un altro nel back office. Ogni terminale altererebbe le richieste all'AS per riflettere la fonte, e il terminale al banco del negozio potrebbe avere meno accesso in quanto potenzialmente più vulnerabile.
Sono a conoscenza delle principali istanze, ma la mia comprensione è che questi sono solo considerati come principi separati e l'utente deve avere credenziali diverse per ogni istanza. Sto cercando di ottenere qualcosa che entrambi permetterebbero controllo dell'accesso più granulare e consentire all'utente di utilizzare un solo set di credenziali.
Per quanto riguarda la fattibilità, il mio primo tentativo di descrivere uno schema in cui questo potrebbe essere raggiunto sarebbe quello di apportare le seguenti modifiche allo schema di Kerberos:
-
Tutte le entità di origine hanno coppie di chiavi e principi distinti dai principali utilizzati dagli utenti.
-
Il principal ricevuto da un AS può essere il principal di un utente o il principal di un utente che è combinato con l'entità di una fonte per formare un principal composito.
-
I principal compositi sono ovviamente principi validi e sono creati per essere riconoscibile in modo che chiunque conosca questo schema possa farlo riconoscere e scomporre l'entità per recuperare gli ID originali, e farlo in modo tale che entrambi gli ID possano essere riconosciuti come entrambi un ID sorgente o utente. Inoltre, gli ID sorgente e utente sono limitati per consentire la creazione di principi compositi non ambigui.
-
L'entità che modifica i messaggi dal client sostituirebbe l'entità inviata all'AS in rotta con un'entità composita che aveva un ID origine codificato in esso.
-
Se all'AS viene inviato un principal composito, crittografa la risposta usando le informazioni condivise dell'utente e quindi crittograferanno questo messaggio crittografato utilizzando la chiave pubblica associata al principale dell'origine. La mancata individuazione del principal dell'utente o del principal dell'utente darà la stessa risposta come se una ricerca fosse stata eseguita con un principio ordinario.
-
Se all'AS viene inviato un principal non composito, l'AS utilizzerà semplicemente l'entità ricevuta come principale dell'utente e si comporterà normalmente.
-
L'entità sorgente che ha alterato il messaggio dal client in rotta verso l'AS decodificherà i messaggi provenienti da AS utilizzando la propria chiave privata, e quindi inviare il messaggio al client. L'entità non ha il messaggio di testo chiaro in quanto non conosce il segreto dell'utente (né la password né la chiave privata).
Non penso che questo altera il protocollo in modo significativo, dovrebbe consentire ai clienti ingenui di continuare a lavorare e probabilmente potrebbe essere raggiunto alterando la logica che crittografa i messaggi per il client sull'AS. Permetterebbe a un utente di avere un set di credenziali e quindi l'accesso da una determinata origine sarebbe interamente determinato dall'AS.
Ovviamente ci sono degli svantaggi, ma penso che quanto sopra sarebbe adeguato nel mio caso d'uso. Le macchine utilizzate dovrebbero essere attendibili, ma questo è lo stesso con Kerberos comunque, e gli utenti dovrebbero essere fidati di non sovvertire la coppia di codice sorgente si accoppia, ma ciò è possibile nel mio caso d'uso. Ovviamente qualsiasi principale non composto dovrebbe essere dato agli utenti minimi privilegi per prevenire attacchi di escalation.
Potrebbe essere stato implementato, potrebbe far parte di uno schema diverso o potrebbe esserci qualcosa di più appropriato ai miei bisogni; Sono abbastanza nuovo in questa particolare area così Sto ancora cercando di capire le cose. Se sono molto fuori strada, dire. Ho cercato qualcosa in questo senso ma non ho ancora trovato nulla che corrisponda a quello che sto descrivendo.