The topic of conditional access seems to be on everyone's lips right now. Good thing!
It is an important part of Zero Trust concepts, but what does it mean?
Zero Trust concepts
Let's look back for a moment. A directory, application & data, there was a time when everything was often inside a company, sometimes even a building. Securing this scenario meant being positioned against attacks "from the outside", having firewalls and secure access available. If you stayed within these boundaries, a domain user, for example, was trusted in principle.
Then came collaboration with other companies, came the cloud, and it is considered now insecure to trust a user, but where does that go?
Zero Trust means that it is no longer enough to log in as a user, and possibly with a second factor. There are other factors that can be used - such as device compliance, a specific source network (known or not), and so on. That can be combined with the actual user login of various methods.
Since there is no single product for "Zero Trust", but usually concepts that add up to a "big picture", I describe here only one possible part of the concept, namely authentication and then authorization to use resources.
Workspace ONE Access
This tool represents the hub for authentication of the Workspace ONE suite. It could be called “authentication broker”.
With Workspace ONE Access we get the ability to aggregate multiple IdP (Identity Provider) sources like Okta, Azure AD or Ping Identity as well as ADFS and Active Directory to use centrally for logon. There are a huge number of possible authentication methods to be as flexible as possible to get authorized to specific resources.
Possible scenario
Workspace ONE Access also can act as an IdP itself, e.g. for logon to office applications. This makes it possible to use many different login methods, including device compliance from Workspace ONE UEM.
These methods can be used in a policy to allow certain user groups from known or unknown source networks and certain client applications (OS, browser) to log on using methods in a certain order and combination, or to prevent logon.
These configurations can be provided in different combinations, similar to a firewall pulls "the first matching" rule.
Each rule can be structured as follows:
In this case, the Workspace ONE App or Intelligent Hub, whether coming from internal or external, must log in using a combination of specific authentication methods, here combined with device compliance from Workspace ONE UEM.
What are the benefits?
- Arbitrary combination of logon methods.
- Configurable per application if required.
- Fallback methods are possible, e.g. in case someone does not have his smartcard at hand.
- Compliance rules from Workspace ONE UEM are very extensive.
Example Microsoft Office:
User opens Teams (Office Domain is more springy to Workspace ONE Access than IdP, therefore the rules there are valid)
Lt policy rule for browser (user agent of Teams app) the appropriate rule is applied, if necessary for a single user group, e.g. based on a certificate installed by UEM and the device compliance status then authentication is performed without the user having to do anything further.
If there is no certificate on the device, a fallback combination of methods can be applied. This not only maximizes capabilities, but significantly increases overall security.
I hope you were able to shed some light on what conditional access is with this article! Stay tuned for more information.
