creare un provider di identità personalizzati WS-Federation utilizzando un servizio WCF

Question

Questo si riferisce a, ma sono abbastanza sicuro che non duplicare, la mia domanda: Looking for a secure and robust STS implementation

Dal chiedendo che, qualche input da parte delle imprese, e alcune ricerche, Mi ha portato a credere che invece di implementare un servizio token sicuro per avvolgere il mio provider di identità personalizzato, posso delegare l'emissione di token al provider di identità stesso.

Il provider di identità è un servizio WCF che restituisce una raccolta di attestazioni quando autentica correttamente un utente, in base ad alcuni dati di identificazione per l'utente. Per esempio.

[ServiceContract(Namespace = "http://namespace")] 
public interface IIdService 
{ 
    [FaultContract(typeof(IdServiceFault))] 
    [OperationContract] 
    ICollection<Claim> Authenticate(string idDatum1, string idDatum2); 
} 

dove Claim è Microsoft.IdentityModel.Claims.Claim. Attualmente sono bloccato con un esempio di implementazione STS di qualità, come progetto di un sito Web, ma se possibile, vorrei semplicemente spostare l'attività di emissione e firma di token nel provider di identità e alla fine qualificarlo come Provider di identità WS-Federation, che posso includere in seguito nei provider di Controllo accesso di Azure.

Se ciò è possibile, cosa devo fare nel servizio WCF?

Answer 1

"Uno non si limita a battere un provider di identità WS-Federation" - ci sono molte complessità necessarie, principalmente per garantire la sicurezza, l'integrità e la provabilità delle affermazioni asserite.

NON vuoi che questa roba sia sbagliata - guarda cosa è successo a Target, Home Depot, Sony e altri ultimamente!

Vi incoraggio vivamente a leggere e rileggere Michele Leroux Bustamante "Building A Custom Security Token Service" article fino a comprendere a fondo il ruolo di un STS e le varie complessità coinvolte nel farlo.

Si noti che per creare un STS sicuro è necessario supportare SAML, WS-Security, WS-Trust, WS-Federation e utilizzare SSL per il trasporto sicuro di token e dati. Avrai bisogno di attuare attentamente le varie fasi del protocollo di comunicazione necessario per consentire la federazione delle informazioni di identità.

Una volta che hai approfondito l'argomento, avrai una migliore comprensione del motivo per cui è consigliabile creare un servizio di facciata come servizio di facciata che si trova accanto/in primo piano del tuo servizio Identity esistente - piuttosto che "inquinare" il servizio esistente con le considerevoli complessità coinvolte nella costruzione di un STS.

Se tutto questo sembra un gran lavoro, è (e dovrebbe essere - la sicurezza è davvero, DAVVERO difficile!).

Vorrei fortemente consiglia di considerare l'utilizzo di Identity Server di ThinkTecture invece di crearne uno proprio. L'impressionante Dominick Baier & squadra hanno fatto un lavoro impressionante di costruzione di un robusto, ben progettato, open-source Identity Server che supporta WS-Fed così come OpenID, OAuth, ecc