Free Demo Contact

Access Management: Context-based access

1 July 2025

The Access Management module of Tools4ever’s HelloID identity and access management (IAM) solution enables fine-grained control over access to applications and systems. One capability is granting access based on context, also known as Conditional Access. You define specific requirements that a user must meet to obtain access to an application or system. This raises the security level of your IT environment.

Traditionally, users sign in to applications and systems with a username and password. In many cases, multi-factor authentication (MFA) has been added, requiring users to authenticate with a unique code as well. Conditional Access makes it possible to set additional requirements and add extra security to your sign-in process.

Portal application rules and application access rules

You can apply Conditional Access to specific applications and systems, as well as to the HelloID dashboard. In the latter case, you secure all applications and systems that HelloID provides access to through Single Sign-On (SSO).

You configure Conditional Access by setting rules, which we refer to as portal application rules and application access rules, respectively. These rules provide extensive flexibility; you decide which security requirements to enforce. For example, you can require users to sign in to the HelloID dashboard using Conditional Access and then impose additional requirements to sign in to specific applications.

Common use cases for application access rules include:

  • Enforcing MFA every time an application is opened

  • Temporarily disabling access to applications

  • Restricting applications to be accessible only through the corporate network

  • Allowing access to an application only through a specific web browser

Configuring requirements

The requirements you can set are diverse. A fairly standard requirement is the use of a specific identity provider and that the user must be a member of a specific user group. You can also set various additional requirements, such as the country from which a sign-in attempt may originate, or even the IP range within which the IP address used to sign in must fall.

Another example is the time of day when users may sign in. In many cases, employees do not need access to your applications and systems in the middle of the night or during weekends. You can choose to restrict sign-in to, for example, 8:00 AM to 6:00 PM on business days. This ensures that bad actors can never gain access outside regular office hours.

The requirements can go further. You can restrict sign-in attempts to specific device types, such as Windows and macOS systems or Android and iOS devices. You can also restrict sign-in attempts to specific web browsers such as Google Chrome, Microsoft Edge, or Mozilla Firefox.

You can also enforce the use of MFA. Multiple MFA methods can be allowed as well. Some users may use SMS-based MFA, while others prefer to receive their MFA code through the HelloID Authenticator.

Prioritizing requirements

If a user meets one of the requirements, HelloID approves the sign-in attempt. You decide which requirement has priority. For example, you can configure HelloID to check the device type first and then the web browser used to sign in. In that case, users receive access only if they sign in from a Windows system or through the Mozilla Firefox web browser.

Note: stacking rules is not possible. HelloID grants access as soon as the user meets one of the configured rules. The IAM solution does not then check whether the user also meets the other rules. If the user does not meet the rule with the highest priority, HelloID automatically checks whether the user meets one of the other configured rules. It is possible to combine multiple requirements within a single rule, for example that users must sign in from a specific country and must always be authenticated through MFA. In that case, users receive access only if they meet all requirements defined in that rule.

Permit or deny

You can define requirements that a user must meet to gain access, which we call a permit rule. You can also define requirements based on which HelloID denies access, which is called a deny rule. This allows you to block access from a specific country, from a particular operating system, or through a particular web browser.

HelloID always checks first, regardless of the priorities you set, whether a user matches one of the deny rules. If so, HelloID blocks access without evaluating the permit rules further. If a user does not match a deny rule, HelloID then checks whether the user meets a permit rule and applies the priorities that you configured.

Note: if you start using permit and deny rules, HelloID will by default deny access to every user who matches a deny rule or who does not meet a permit rule. Due to configuration errors, it is possible to lock yourself out as an administrator. If you unexpectedly lose access as an administrator, contact the Tools4ever support team for assistance.

Get started

Ready to get started with HelloID Access Management? You can find more information about the capabilities on our website. Do you have questions? Contact us!