To begin, first investigate what use cases you need to fulfill. Here is a small list of examples.
- Will users mainly be working from central locations or are they geographically dispersed?
- Do you have (or plan to implement) a standard onboarding process with supplied hardware and credentials or are users encouraged to bring their own devices?
- Will you be solely focused on application logon or will you need to include device sign-in as well?
- Do the applications have local clients, or are they accessed via a browser? Do you have a SSO solution in front of any of them already?
Active Directory Federation Services (AD FS) offered entities with existing active directory environments a way to bridge cloud services with local authentication. It is most commonly found in orgs that adopted some cloud services before moving to a fully hybrid model. Smart card authentication can be tied into this model, leveraging an on-premise CA, your local AD acting as your IDP and Azure CBA playing the role of an RP. This provides a comfortable level of support for many platforms, but may call for special attention to be paid to the identity that is being leveraged.
📄 Use-Case Guide - Transitional state hybrid architecture with on-premises AD FS + Azure AD
Leveraging a hybrid infrastructure that includes federation via AD FS can be thought of as a transitional state, with the end goal being relying on Azure CBA for the majority of phishing resistant authentication tasks. In this model Azure AD functions as your IDP, and not just as an RP. This simplifies and expands on capabilities while maintaining the highest level of assurance.