The previous post compared idsrv3 to other Microsoft Identity products from a protocol perspective.
From a wider perspective, a key point is that it is extensible.
ADFS 2.x ran on IIS and was essentially a web application.
This meant you had access to the form code, css and html. As a result, you could extend ADFS by hiding providers in the HRD, adding MFA, allowing different kinds of user names, displaying why authentication failed e.g. account lockout and so on.
However, it resulted in a number of "insecure" installations and so the architecture of ADFS 3.0 onwards changed to a black box running on http.sys (and thus no IIS) with very limited customisation.
ADFS and Azure AD are pretty much locked down and there is a good argument for supporting this approach.
idsrv3 takes the opposite approach - it is designed to be extensible and supports plugging in Katana middleware.
Katana allows you to pick and choose functionality you want - both vertically (the ASP.NET framework) and horizontally (you can mix and match authentication e.g. FBA, WS Fed, SAMLp and certificate in the same application).
In addition, it's open source so you can enhance it any way you like e.g. custom login workflows / registration etc. Ideally, all the enhancements should be done using the extensibility points rather than altering the code.
I've used it in a number of projects to essentially extend ADFS by federating ADFS and idsrv3 and then "altering" and "extending" on the upstream and downstream paths.
Unlike ADFS, idsrv3 has no dependency on AD. It does not need to be installed on a
domain controller and can be hosted in IIS, NT Services, embedded, on-premises or in the cloud on Azure or AWS.
However, with great power comes great responsibility. idsrv3 is a certified security product.
Review any changes you make from a security point of view.
Enjoy!
No comments:
Post a Comment