1. Federated Web SSO: متداول ترین و رایج ترین سناریو این گزینه است. این مدل معمولا به شکل پلی روی Firewall های مختلف عمل می کند و تنها ارتباط Trust موجود یک Federation trust است که همواره به شکل One-way (یک طرفه) از Resource Organization به Account Oranization است. (مشابه شکل پیشین در قسمت، نحوه تعیین هویت)

2. Federated Web SSO با Forset trust: در این مدل سازمان از دو جنگل AD DS استفاده می کند. اولی برای شبکه داخلی که به آن به اختصار “جنگل داخلی” می گوییم و دیگری برای شبکه خارجی که به آن “جنگل خارجی” می گوییم. جنگل خارجی در واقع شامل perimeter network می شود یا روی آن واقع است. یک رابطه Trust در این حالات بین جنگل داخلی و جنگل خارجی ایجاد می شود که اغلب به صورت one-way (یک طرفه) کفایت می کند. همچنین یک Federation Trust از Resource Federation Server (در perimeter network) به Account Federation Server (در شبکه داخلی) ایجاد می گردد. تا کنون کاربران داخلی توانستند به Web App موجود روی perimeter network دسترسی داشته باشند. برای کاربران خارجی، در جنگل خارجی دارای یک اکانت هستند.

تذکر: هر یک از چهار رول اضافی Active Directory یعنی AD LDS، AD CS، AD RMS و AD FS به هدف افزایش اختیارات و توانمندی های شبکه داخلی ایجاد می شوند. افزودن یک جنگل AD DS دیگر کاری است که باید بسیار با دقت صورت گیرد و تا حد ممکن از آن پرهیز کرد. بر خلاف تصور ظاهری برخی افراد، امنیت در حالت دو، در وضعیت نا مناسب تری از وضعیت یک است. توجه داشته باشید که برقراری یک Forest Trust به معنای باز شدن یک پورت روی فایروال است که معمولا بسته است.

3. Web SSO: زمانی که تمام کاربران روی شبکه خارجی اند و روی شبکه داخلی دارای اکانت نیستند، باید تنها Web SSO پیاده سازی شود. Web SSO باعث می شود تا کاربران برای استفاده از چند Web App مختلف تنها لازم باشد یک بار Login کنند. در این حالات لازم است تا وب سرور ها دارای دو Network Interface Card یا NIC باشند که یکی از کارت شبکه ها به داخلی و دیگری به شبکه خارجی متصل باشد. همچنین این شرط برای Federation Proxy Server نیز بر قرار است. مشابه شکل زیر

سناریو های متداول و مناسب شماره 1 و 3 هستند. به صورت ایده آل تمام کاربران Web App روی AD DS دارای اکانت هستند. 

آشنایی با اجزاء AD FS

جدا از سرویس رول ها که بحث شد، تکنولوژی AD FS به اجزا و مولفه های بسیاری وابسته است از جمله:

1. Claims

2. Cookies

3. Certificates

جهت درک بهتر سرویس AD FS لازم است تا با این سه مولفه فوق و نقش آن ها در AD FS آشنا شویم.

Claims

در ساده ترین حالت می توان گفت، Claim ها (اداعا نامه ها) توضیحاتی است که هر شریک (Partner) در Federation Relation در مورد کاربران ارائه می دهد. به طور مثال، نام کاربر، عضویت در گروه ها، مجوز های خاص، کلید Certificate ها و… . Claims در واقع پایه و اساس Authorization در AD FS است. 3 راه مختلف برای در نظر گرفتن یک Claim وجود دارد:

1. Account Federation Server می تواند از دایرکتوری داخلی یک Query بگیرد و Claims را برای Resource Organization فراهم آورد.

2. Acount Organization می تواند برای Resource Federation Server آن ها را فراهم آورد و پس از فیلتر شدن Claims  کاربر می تواند به Web App دسترسی پیدا کند.

3. Federation Service از دایرکتوری یک Query برای Claims می گیرد و آن ها را پس از فیلتر شدن Claims کاربر می تواند به Web App دسترسی پیدا کند.

سه نوع مختلف Claims در AD FS پشتیبانی می شوند:

1. Claims های نوع Identity (اداعا نامه های هویتی): شامل یک User Principal Name یا UPN است که بیانگر اکانت کاربری User در قالبی شبیه به ایمیل است همانند erfan@contoso.com. به یاد داشته باشید چنانچه چند UPN مختلف لازم است تنها امکان قرار گیری یکی از آن ها در این نوع Claim است، اگر به چند UPN نیاز است باید از Custom Claims استفاده شود. همچنین می تواند یک ایمیل آدرس باشد همانند erfan@contosomail.com. همانند UPN تنها شامل یک مورد می تواند باشد. همچنین می تواند از رشته دلخواه استفاده کرد. توجه شود در این حالت هیچ متدی برای تصدیق یکتا بودن آن رشته وجود ندارد، بنابراین با احتیاط از این گزینه استفاده شود.

2. Claims های نوع Group: گروه های کاربری که کاربر در آن عضو است می تواند در یک Claim معین شوند.

3. Claim های نوع Custom: چنانچه اطلاعات خاص دیگر لازم باشد همانند شماره پرسنلی از این گزینه می توان استفاده شود.

Cookies

AD FS به اضافه ی Claims از Cookies نیز استفاده می کند. AD FS از Cookies برای Authentication کاربر استفاده می کند. Cookie روی Browser کاربر (در محل فیزیکی تعیین شده در Browser) جای می گیرد تا از SSO پشتیبانی به عمل آید. Cookie در واقع تمام Claim های مربوط به کاربر را شامل می شود تا در دفعات استفاده بعدی کاربر نیاز به طی کردن فرآیند تعیین هویت را نداشته باشد. Web Agent و Federation Server هر دو باهم Cookies ها را صادر می کنند تا از قرار گیری Public Key و Private Key روی یک سرور جلوگیری به عمل آید. توجه داشته باشید که Cookie اما رمز نگاری شده نیست. این یک دلیل مهم است برای آنکه تمام ارتباطات از طریق TLS یا SSL صورت گیرد.

در AD FS دو دسته Cookie مختلف صادر می شود:

1.Account Partner Cookie: همانطور که گفته شد، در طی مرحله تعیین هویت یک Cookie صادر می شود تا کاربر دوباره لازم نباشد فرآیند تعیین هویت را طی کند. این Cookie به صورت Signed یا رمزنگاری شده نیست.

2. Sign-Out Cookie : هر زمان که Federatin Services یک Token  صادر می کند Resource Partner یک Sign Out Cookie می سازد.

Certificates

برای امنیت ارتباط AD FS به AD CS جهت صدور انواع Certificate هایی که استفاده می کند وابسته است.

1. Federation Server: در Federation Server باید هم Server Authentication Certificate و هم Token-Signing Certificate نصب شده باشد.

2. Federation Server Proxy: در Federation Server Proxy لازم است تا Server Authentication Certificate نصب شده باشد.

3. AD FS Web Agent: در Web Agent نیز باید Server Authentication Certificate نصب شده باشد.