Niniejszy text jest opisem do slajdów, które były wykorzystane do prezentacji dla osób zainteresowanym serverem Longhorn, 12.iv.2oo7 w siedzibie Microsoft.

wprowadzenie

Zarówno AD FS jak i AD RMS są mechanizmami, które pojawiły się jako dodatkowe komponenty w Windows 2oo3 R2. nie są to więc rzeczy niedostępne obecnie, jednak w2k8 wprowadza sporo modyfikacji. przede wszystkim RMS i FS są dodane jako role serwera i nijako zintegrowane z resztą komponentów systemowych. dzięki temu skorzystanie i utrzymywanie tych mechanizmów w środowisq produkcyjnym powinno być dużo prostrze, działanie wydajniejsze. W niniejszym doqmencie będzie krótko opowiedziane o Usłudze Federacyjnej dla osób, które się z nimi jeszcze nie spotkały – aby zachęcic już dziś do testowania – na w2k3 lub na becie w2k8. Większa część prezentacji poświęcona jest demonstracji praktycznej tak, aby przekazać podstawową teorię ale w pierwszej kolejności pokazać jak to wyglada w LHS – ponieważ spodziewam się, że więkoszość osób jest ciekawa również ogólnego wizerunq nowego systemu

Czego dotyczyc bedzie prezentacja?

Najpierw ogólnie przedstawione będzie czym AD FS w ogóle jest i jakie jest jego zastosowanie, przedstawiając możliwe scenariusze zastosowania.
Następnie przedstawione zostaną podstawowe zalety tego rozwiazania – FS nie jest mechanizmem trywialnym i składa się z kilq komponentów, które należy odpowiednio wdrożyć zależnie od wybranego scenariusza – następnie więc przedstawione zostaną własnie komponenty, jakie skladają się na całościowe rozwiązanie.

W dalszej części chcialem sqpić się na przedstawieniu wdrożenia scenariusza B2B, przy okazji demonstrując niektóre z elementów nowego interfejsu w2k8 i zwrócić uwagę na kilka szczegółów.
Na końcu prezentacji zamieszczone zostały linki, które mogą być przydatne w samodzielnej exploracji.

CZYM JEST AD FS

Active Direcotry Federation Services jest w zamyśle mechanizmem, który ma umożliwić skorzystanie z AD nie tylko jako bazy użytkowników lokalnych, z zastosowaniem dla sieci korporacyjych. Plany rozbudowy AD siegają dużo dalej – do zastosowania AD jako centrum autentykacji rownież w zastosowaniu otwartym – w Internecie.
Z problemami tożsamosci na codzień spotyka się na pewno każdy z was – choćby posiadając kilka adresów email, czy kont na różnych forach, gdzie do każdego jest oddzielne hasło i inna nazwa użytkownika. W suqrs idą proste aplikacje, które pomagają zapisywać linki wraz z danymi oraz opcje zachowywania poświadczeń przez przeglądarki, ale to trochę dalekie od wizji łatwego korzysania z Internetu i stosunkowo mało bezpieczne. Sytuacją idealną byłaby możliwość uruchomienia komputera, zalogowania się do systemu i powiedzmy jednokrotnie w przeglądarce, a potem już korzytania z zasobów Internetu z pojedynczą tożsamością. Podstawową abstrakcją jaka się narzuca, byłoby stworzenie jednej globalnej bazy użytkowników i logujac się, każdy loguje się do takiego 'ogólnoświatowego AD’. Takie podejście jednak jest błędne i z wielu względów nie ma racji bytu – np. kto miałby to utrzymywać, musiałyby istnieć jakieś opłaty, dochodzi problem łatwości kradziezy tożsamości etc.
Od jakiegoś czasu rozwijana jest idea Identity Metasystem, do której należy projekt infoCard oraz m.in. właśnie AD FS.
AD FS jest podejściem z goła odmiennym niż prezentowałem poprzednio – zamiast starać się przechowywać wszystkie informacje w jednym miejscu, wykorzystywana jest 'spychologia’. Termin ten może źle się kojarzy, ale działa to podobnie jak w przypadq zaufania certyfikatów lub trustów – czyli jeśli ja ufam Zdziśkowi i wiem, że zdzichu nie przyśle mi przypadkowej osoby, to jeśli się ktoś pojawia od Zdzicha [i potrafi to poświadczyć], daję mu dostęp do określonych zasobów. Dzięki temu ja nie zajmuję się identyfikacją pojedynczych osób – spycham to na Zdzicha, a on z jakichś określonych względow, i tak najlepiej wie kto do tych zasobów ma mieć dostep.

Jedną z podstawowych zalet AD FS jest oparcie o znane i ogólnie uznane standardy Web Services [WS-*]. W przypadq FS wykorzystywane są 3 podstawowe elementy opisujace WS – Federation, Trust i Security. W praktyce oznacza to tyle, że system ten jest wspierany przez wszystkie klienty na dowolnej platformie, nie zawęża działania do systemu Windows z IE. Da się go również integrować z innymi systemami opartymi o te same standardy.

3 podstawowe scanriusze zastosowania to SSO [Single Sign-On] dla B2B, B2C i B2E czyli:

  • bussiness 2 client – przykładem może być strona wsparcia – np. producent sprzętu dający możliwość zalogowania się do własnego profilu
  • bussines 2 enterprise – wielooddziałowa firma obejmująca cały glob, i udostępnienie aplikacji webowych wszystkim użytkownikom
  • bussiness 2 bussines – dwie oddzielne firmy, które mają mieć możliwość korzystania z tej samej aplikacji – i tego dotyczyć własnie będzie demo.

USŁUGI AD FS

Całe rozwiązanie FS składa się z 3-4 komponentów w których skład wchodzą:

  • sama usługa FS, składająca się z jednego lub więcej serwerów, realizują tą samą politykę bezpieczeństwa. Jak pokże demo, usługa ta przy rozwiązaniu B2B musi być zainstalowana w obu firmach.
  • następnie usługa proxy dla FS. Jest niezbędnym elementem, aby zapewnić odpowiednie bezpieczeństwo rozwiązaniu, w innym wypadq serwer AD musiałby być opublikowany bezpośrednio do Internetu. FS Proxy korzysta ze standardowego protokołu z grupy protokołów WS-* WS-Federation Passive Requestor Profile
  • finalnie sama aplikacja/usługa web musi umieć z takim logowaniem się zmierzyć. Są dwa podstawowe rodzaje aplikacji – uwieżytelniające za pomocą standardowych protokołów systemowych – Windows token-based, oraz świadome webserwisów – claims-aware. Dla obu typów stworzony został agent, umożliwiający zastosować oba rodzaje aplikacji.
  • tak na prawdę dochodzą jeszcze inne serwisy, które nie są wprost wymienione, ale są niezbędnymi składowymi – jest to oczywiscie AD oraz usługi certfikatów. W demonstrowanym scenariuszu serwer certyfikatów nie będzie pokazany.

SCENARIUSZ

Zajmiemy się scenariuszem B2B. Na początek podstawowe pytanie – w jaki inny sposób można byłoby go wykonać, bez FS? odpowiedzią są trusty między lasami. To jest też dobry przykład, żeby wyjaśnić na czym polega różnica oraz 'spychologia’. W przypadq trustów przydzielanie dostępu do zasobów odbywa się po stronie osoby udostępniającej zasób – co jest dość logiczne w standardowym modelu administracji zasobami. Czyli jeśli firma F ma aplikację A, to każda osoba, która chce mieć dostęp do niej, musi być obsłużona przez administratora z firmy F – np. dodana do odpowiedniej grupy bezpieczeństwa, dającej dostęp do tej aplikacji. W przypaq FS odpowiedzialność ta jest zepchnięta na partnera – to jest aplikacja firmy F ale dostęp do niej muszą mieć pracownicy przedsiębiorstwa P. To nie administrator firmy F będzie się dowiadywałi decydował, kto zostnie wydelegowany do pracy z tą aplikacją – zarówno od strony bussinessowej jak administracynej jest to obowiązkiem przedsiębiorstwa P i nie powinno się tym obarczać swoich adminów. Dla tego w firmie F zakłada się grupę definiującą 'jeśli uwieżytelniony przez P to ma dostęp’, natomiast przynależność do grupy definiuje się po tamtej stronie. Dodatkowo dochodzą kwestie bezpieczeństwa – ponieważ zestawienie trustu wymaga bezpośrednieniego połączenia pomiędzy kontrolerami domeny, co nie zawsze jest możliwe.

*****DEMO*****

Następnie prezentowana była demonstracja przygotowania na podstawie doqmentu step-by-step guide to configure AD FS. Doqment ten powinien być wkrótce dostępny na stronach Microsoft – wtedy umieszczę link.

-o((:: sprEad the l0ve ::))o-