. N-tier tożsamości i autoryzacji w architekturze usług

Question

Buduję aplikację, w której wymagania wydają się standardowym problemem (przynajmniej dla mnie) ... Mam Web.UI na podstawie klientów asp .net mvc & od iphone, andriod & blackberry.

Więc rozsądną rzeczą do zrobienia jest przeniesienie całej mojej logiki biznesowej do warstwy usług, która może być dostępna przez http. Ta warstwa usług musi akceptować żądania z kontekstem użytkownika (tożsamością) iw pewien przyjemny sposób wykonywać autoryzację niezależnie od tego, z którym typem klienta komunikuje się (mam nadzieję?).

Przez rok robiłem 3-miesięczny koncert z udziałem W.I.F. (Windows Identity Foundation) w hybrydowej lokalnej architekturze w chmurze &. Lubię to. Trzy rzeczy, które uderzyły w akord, to (1) uwierzytelnianie na zewnątrz i nie dbanie o to, jak to się stało, (2) usuwanie logiki autoryzacji z logiki biznesowej, (3) autoryzacja na podstawie roszczeń.

W ciągu ostatniego roku słyszałem i obserwowałem wszystko o usługach wypoczynkowych "nowym, hipisowskim sposobie robienia rzeczy". Więc chociaż świetnie, spróbujmy. Po tym, jak zacząłem grać wokół kodowania, zacząłem się bardzo zagmatwać (a następnie przeczytać około 10 godzin wczoraj bez pisania kolejnej linii C#). Nadal jestem zdezorientowany wszystkimi rozmowami SOAP, REST, WS. * I Http, SAML i SWT. Naprawdę nie chcę tego wątku na ten temat, ponieważ jest wystarczająco dużo tego, co mówi na temat stackoverflow, ale czuję, że mam wybór między dwoma obozami, kiedy tak naprawdę nie mam ochoty na jedno lub drugie ale kawałki od każdego?

Dla mnie 3 punkty, o których wspomniałem powyżej o WIF, nie wydają się być koncepcjami, które powinny być związane z WS. *? Ale mam wrażenie, że oni, a przynajmniej jak WIF przychodzi w tej chwili, czyni ich, bez jakiegoś eksperta (np. Natknąłem się na ten post napisany zaledwie kilka dni temu - http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/).

Pozostałe obszary, o których nie wiem zbyt wiele, to moi klienci (iphone, andriod, blackberry) zdolne do grania w WIF, czy to ten sam STS, który rzuca im token SAML i zachowują się jak przeglądarka i przekazać go z powrotem w nagłówku, tak jak każdy inny klient? Tak, będę musiał się tego dowiedzieć, ale jeśli to jest złamanie umowy z W.I.F i dowiedziałem się o tym zaraz po zamieszczeniu tego, to przynajmniej mogę się od niego skupić.

Wreszcie, aby dodać jeszcze jedną rzecz do miksu. Naprawdę nie chcę o tym myśleć. Chcę korzystać z dostawcy uwierzytelniania/tożsamości innej firmy - http://www.janrain.com/products/engage - który, jak sądzę, korzysta z OpenID. Czy to pasuje do W.I.F. czy mogę po prostu utworzyć nowy token SAML z OpenID i używać WIF od tego momentu.

Pod koniec tego bełkotu chcę wrócić do miejsca, w którym zacząłem, ponieważ jest coraz bardziej skomplikowane, im więcej pytań zadaję i tym więcej opcji rozważam.

Czy istnieje warstwa usług (w WCF), która komunikuje się z różnymi klientami nie -.net, która wymaga kontekstu tożsamości i autoryzacji tak dziwnego? Jeśli zbudowałeś coś takiego, jak do tego doszło?

Answer 1

Jeśli masz wiele urządzeń, jednym ze sposobów na uzyskanie tego samego rozwiązania we wszystkich jest ustalenie najniższego wspólnego mianownika.

Zakładając, że wszyscy Twoi klienci obsługują pliki cookie. Jeden ze sposobów wykonania tego:

• Posiadać system uwierzytelniania oparty na pliku cookie.
• Cache wszystkie informacje autoryzacji po stronie serwera, połączony z sesją lub klucza w pliku cookie
• dla każdego żądania sprawdzenia autoryzacji

Nie tak eleganckie, jak przy użyciu tokenów SAML, ale robi krzyż pracy platforma/urządzenia.

iPhone obsługuje ciasteczek http://support.apple.com/kb/HT1675

Blackberry obsługuje ciasteczka http://docs.blackberry.com/en/developers/deliverables/11844/feature_cookie_storage_438273_11.jsp

Answer 2

Jak WIF mówi WS-Trust/WS-Federation pod maską można wystawiać uwierzytelniania roszczeń opartych na warstwie usługowej.

W tym artykule pokazano, jak utworzyć WCS STS, który będzie rozmawiał z klientami zewnętrznymi za pomocą tych protokołów. http://msdn.microsoft.com/en-us/library/ee748498.aspx

Z autoryzowanego punktu widzenia w warstwie usług można skorzystać z niestandardowego menedżera autoryzacji, aby sprawdzić, czy zgłoszono roszczenia. http://msdn.microsoft.com/en-us/library/ms731774.aspx

do podłączenia zewnętrznych usług osobistych, takich jak OpenID i dodawać własne roszczenia do tych generowanych przez WIF następnie można podklasę z ClaimsAuthenticationManager następująco:

public class MyClaimsAuthenticationManager : ClaimsAuthenticationManager {

public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal) 
    { 
     if (!incomingPrincipal.Identity.IsAuthenticated) 
     { 
      return incomingPrincipal; 
     } 

     //TODO: obtain user profile claims from external source, i.e. database, web service    
     // below code demonstrates how to custom claims to the current principal 
     // (which are then persisted for the lifecycle of the user's browser session)    

     IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity; 

     identity.Claims.Add(new Claim(ClaimTypes.Email, "dave@dave.com")); 

     return incomingPrincipal; 
    } 
} 

Musisz powiedz WIF, aby użył własnego menedżera roszczeń w pliku Web.config, ustawiając parametr konfiguracyjny claimAuthenticationManager.

Mam nadzieję, że to pomoże.

Answer 3

Zamierzam wziąć pęknięcia w odpowiedzi na swoje pytanie nieco bardziej abstrakcyjnie ...

Zanim zacznę, moje tło jest MS tendencyjne, więc nie może być równy (lub lepsza) opcje dostępne z innych źródeł.

Dwie referencje, które znalazłem bardzo przydatny:

1) Przewodnik tożsamość roszczeń opartych i Kontroli Dostępu

http://msdn.microsoft.com/en-us/library/ff423674.aspx

2) Programowanie Identity Foundation systemu Windows

Autor: Vittorio Bertocci Dostępne w wersji papierowej w różnych formatach:

T tutaj jest wiele innych źródeł, ale te dwa obejmują kilka scenariuszy i dają dobre informacje podstawowe dla każdego, kto chce przyspieszyć swój punkt wyjścia.

Zachęcam inne plakaty do wypełnienia luk i błędów :) Prześledziłem mnóstwo szczegółów technicznych, aby skupić się na zadawanym pytaniu.

sposób, w jaki przerwać stowarzyszoną identyczność dół jest, w przybliżeniu, w następujący sposób:

1. Zastosowanie (a) [aplikacji (S)]
2. usługi (ów) uwierzytelnianie [STS (e)]
3. Zastrzeżenie (y) [zgłoszenia (s)]
4. zaufania związku (ów) [Trust (s)]
5. sposób transportowa (y) [transportowa (s)]

STS jest odpowiedzialny za weryfikację tożsamości użytkownika i uzyskanie potwierdzenia niektórych roszczeń. Robi to, podając (1) podpisaną wiadomość typu blob zawierającą roszczenia lub (2) unikatowy identyfikator, który osoba trzecia może wykorzystać do sprawdzenia roszczeń.

Aplikacja, która chce zapewnić użytkownikowi usługę, może "zaufać" STS, aby dostarczyć mu roszczenia, które może wykorzystać do prawidłowej pracy z użytkownikiem, a tym samym ułatwia jej weryfikację (między innymi takie jak utrzymywanie scentralizowanych metadanych, ale dygresja).

Istnieje również możliwość, aby STS "zaufał" innym STS, mówiąc w zasadzie: "Jeśli powiesz, że ta osoba to Joe Smith, a oni mają role X, Y i Z, to będę ręczyć za to, co mówisz! "

Więc parafrazując:

App (s) "Trust" STS {które mogą z kolei "zaufanie" Another STS}, aby zapewnić mu/im roszczenie (s)

** przełączania biegów * *

SOAP vs REST

Pod koniec dnia SOAP i REST są oba rodzaje usług, nazwijmy ich roszczeń konsumentów. Oboje chcą, aby ktoś dał im wiadro pełne roszczeń, aby mogli wykonać swoją pracę i wysłać kilka rzeczy. Dodatkowo, oba typy usług mogą być prezentowane z roszczeniami za pomocą ciągu zapytania za pomocą tokena (zakładając, że usługa może obsłużyć przepisanie URL-a) lub poprzez nagłówek (HTTP dla usług REST i SOAP dla, dobrze, usług SOAP). Tak czy inaczej cel jest taki sam: Prześlij roszczenia lub UID do aplikacji.

WS * vs HTTP

one (wraz z protokołem TCP/IP, SSL, tajnych pierścieni dekoderów, etc) są sposoby przekazywania informacji w tę iz powrotem, choć z różnym stopniem pewności, że ktoś w środku może” t znaleźć sposób na podszywanie się pod użytkownika.

SAML vs SWT

nich (wraz z podstawką 64 kodowania, XML prostym tekstem, etc.) są oba sposoby żądania szeregowania. Te dwa przypadki są zgodne ze standardami, których nie mają inni, aby wszyscy mogli mówić tym samym językiem.

** Wracając do punktu **

Każda z tych kombinacji technologii są ważne (w zależności od zastosowania, niektóre są mniej bezpieczne, inne są łatwiejsze do wdrożenia, a inne działają lepiej na niższym poziomie urządzeń, itp) i są po prostu sposobem, w jaki jedna osoba wykonuje tę pracę w stosunku do drugiej.

Więc jeśli mam.Aplikacja sieciowa, która otrzymała zestaw roszczeń w SAML fomat na potoku WS *, wynikiem końcowym jest to, że apliakcja ma [roszczenia w SAML].

Przy pewnym przetwarzaniu można je przekształcić w [roszczenia w SWT].

Nowe roszczenia można następnie pakować i wysyłać za pośrednictwem protokołu HTTP/SSL do aplikacji Java.

JEŻELI aplikacja Java "ufa" temu samemu STS (lub STS, który "ufa" aplikacjom STS w sieci .Net), wówczas otwiera roszczenia i wykonuje swoją pracę.

• Ekspert szczypanie wspomnieć musi się zdarzyć, pytanie jest po prostu przez kogo iw jaki sposób przezroczysty jest

  1. Dave zapewnia doskonale ważny przykład jeden sposób, aby osiągnąć szczypanie z niestandardowego kodu.
  2. ADFS zapewnia reguły translacji, które próbują przeprowadzić scalanie i tłumaczenie za pomocą konfiguracji.

• Idei usług na odmiennych platform/devices/aplikacji/etc nie jest dziwne w ogóle, to jest dokładnie ten rodzaj scenariusza cały ten materiał jest budowany zająć

jestem próbując zbudować coś takiego, o co pytasz, więc sam pracuję nad tym samym problemem.

Wspomniana usługa Engage umożliwia powiązanie użytkowników aplikacji ze źródłami zewnętrznymi i może zostać wykorzystana do uwierzytelnienia tych użytkowników ... ala "Widzę, że jesteś uwierzytelniony w google jako John@gmail.com, znam Cię jako John Walker o ID 4321, och, zobacz, zmieniłeś swoje ulubione ustawienie kolorów w Google na niebieski ... kontynuuj! "

To, czego nie robi, to zgłaszanie roszczeń do aplikacji, które są specyficzne dla Twojej aplikacji (chyba że wszystko, co musisz wiedzieć, pochodzi z danych Google, w którym to przypadku prawdopodobnie tworzysz mash, a nie aplikację LOB ...

Inny scenariusz:

1. użytkownik przechodzi do aplikacji
2. jest przekierowywany do STS
3. zostaje przekierowany do Google
4. jest zwracany do STS
5. e-mail i ulubionych zastrzega kolor dodaje (za google)
6. Lista ról i roszczeń granicznych zakup dodaje (od konkretnego magazynu danych aplikacji)
7. użytkownik powraca do wniosku
8. użytkownik próbuje kupić $ 10,000 purpurowe widżety i powiedzieć „Cóż, można tylko kupić $ 5000 na kredyt i ... jesteś pewien, że chcesz fioletowy usłyszałem wolisz niebieski?”

Innym miejscem, które chciałbym skierować to jest usługa kontroli dostępu AppFabric oferowana przez firmę Microsoft. (http://msdn.microsoft.com/en-us/library/ee732536.aspx) Oświadczenie: Nie używałem go jeszcze, ale wygląda na to, że szuka tego rodzaju tłumaczeń z dużą ilością ukrytego mięsa.

Answer 4

Podobny problem wystąpił przy użyciu polecenia spring + java; wszystkie koncepcje, których wymaga, znajdują się w .net, więc wspominam o tym tutaj. Znalazłem rozwiązanie, które spring-security posuwa się naprzód (dla moich prostych wymagań autoryzacyjnych). W moim warstwy usług, metody, które wymagają szczególnych uprawnień zadeklarować to poprzez adnotacje (zarówno w interfejsie lub na realizację):

@Secured(MyPermissions.READ, MyPermissions.WRITE) 
void modifyPerson(PersonChanges changes); 

@Secured(MyPermissions.READ) 
Person readPerson(); 

w tym przykładzie ramy bezpieczeństwa (wiosna) owija implementacje obsługa z dynamicznego proxy, które sprawdza, czy moja warstwa autoryzacji umieściła odpowiednie role/uprawnienia o zakresie wątków w kontekście, w którym jest oceniana metoda usługi, jeśli nie zgłoszony wyjątek zabezpieczeń.

Uświadomiłem sobie również, że warto grupować usługi wymagające uprawnień według wzorców adresów URL, aby wymaganie "wymaga uwierzytelnionego zlecenia" było obsługiwane na najwyższym poziomie: np. myapp/services/secure/personService - każdy wzorzec adresu URL wymagający */secure spowoduje przekierowanie na stronę uwierzytelniania, jeśli nie ma informacji uwierzytelniających.

To, co jest naprawdę miłe (ja też) o wymaganiu poświadczeń o zakresie wątku, jest to, że nawet jeśli konfiguracja przechwytywacza HTTP najwyższego poziomu jest wykonana nieprawidłowo (np. Nie można zweryfikować/utworzyć sesji uwierzytelniania), tak długo, jak dynamiczny serwer proxy jest pracując, nie ma mowy, aby logika biznesowa mogła zostać wykonana.

Działa również bardzo dobrze w przypadku usług zagregowanych - jeśli jedna usługa wywoła inną, reguły autoryzacji niższego poziomu są nadal egzekwowane, jeśli nie są prawidłowo zadeklarowane w usłudze złożonej.