utworzyć niestandardową WS-Federation Identity Provider przy użyciu usługi WCF

Question

to dotyczy, ale jestem pewien, nie powielać, moje pytanie: Looking for a secure and robust STS implementation

Od pytając, że niektóre wejście od biznesu, a niektóre badania, doprowadziło mnie do przekonania, że ​​zamiast implementować usługę bezpiecznego tokena do zawijania mojego dostawcy tożsamości, mogę delegować wydawanie tokenów do samego dostawcy tożsamości.

Dostawca tożsamości to usługa WCF, która zwraca kolekcję roszczeń po pomyślnym uwierzytelnieniu użytkownika, na podstawie niektórych danych identyfikacyjnych dla użytkownika. Na przykład.

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

gdzie Claim jest Microsoft.IdentityModel.Claims.Claim. Obecnie utknąłem na przykładzie tylko wysokiej jakości implementacji STS, jako projektu strony internetowej, ale jeśli w ogóle jest to możliwe, chciałbym po prostu przenieść zadanie wydawania i podpisania tokenów do dostawcy tożsamości i ostatecznie zakwalifikować go jako Dostawca tożsamości federacyjnej WS-Federation, który mogę później dołączyć do dostawców usługi Azure Access Control.

Jeśli jest to możliwe, co należy zrobić w usłudze WCF?

Answer 1

"Nie można po prostu zrzucić dostawcy tożsamości federacji WS" - w grę wchodzi wiele niezbędnych złożoności, głównie w celu zapewnienia bezpieczeństwa, integralności i wiarygodności zgłaszanych roszczeń.

NIE chcesz tego źle robić - spójrz na to, co wydarzyło się w Target, Home Depot, Sony i innych!

Gorąco zachęcam do przeczytania i ponownego przeczytania Michele Leroux Bustamante o numerze "Building A Custom Security Token Service" article, dopóki dokładnie nie zrozumiesz roli STS i różnych złożoności w tym procesie.

Uwaga: aby zbudować bezpieczny STS, musisz obsługiwać zabezpieczenia SAML, WS-Security, WS-Trust, WS-Federation i używać protokołu SSL do bezpiecznego transportu tokenów i danych. Będziesz musiał starannie wdrożyć różne etapy protokołu komunikacyjnego, aby umożliwić federację informacji o tożsamości.

Gdy już poważnie zastanowisz się nad tematem, lepiej zrozumiesz, dlaczego dobrym pomysłem jest zbudowanie STS jako usługi fasadowej znajdującej się obok/już istniejącej usługi tożsamości - zamiast "zanieczyszczać" twoją obecną usługę znacznymi zawiłościami związanymi z budową STS.

Jeśli to wszystko wydaje się być wielkim dziełem, to jest (i powinno być - bezpieczeństwo jest naprawdę, NAPRAWDĘ trudne!).

Chciałbym zdecydowanie polecam rozważyć użycie Thinktecture's Identity Server zamiast budować własne. niesamowite Dominick Baier & zespół wykonali niesamowitą pracę budowania solidnej, dobrze skonstruowaną, open-source Identity Server, który obsługuje WS-fed jak OpenID, OAuth itp