Skip to main content

Frequently Asked Questions

Is it possible to send push notifications to own mobile application?​

Within our system, we can add such functionality provided we receive documentation on how to communicate with the specific application. We also offer a free mobile application, Secfense Authenticator, which receives PUSH notifications from our broker. This application can be modified to adapt it to the client's graphical identification.

--

Are there web applications (running on WWW application server) that Secfense UASB does not support learning or manual configuration mode for?​

Secfense UASB is capable of adding an additional strong security layer to any application which uses HTTP protocol to communicate with the user. There are some applications (a small percentage) that cannot be secured automatically. In such cases, the involvement of a specialist who observes traffic from the browser and appropriately configures the Broker is required. These tasks are usually performed during deployment or even during a pilot phase. Deployed applications are supported by us. Therefore, if, for example, after updating libraries that a particular application uses, strong authentication stops working, we repeat the aforementioned process.

--

Is it possible to change the appearance of the MFA selection screen of protected applications?​

Yes. In each case, the system recognizes the language settings in the user's browser and adapts messages accordingly. The messages themselves can also be easily modified within the scope of the protected application. Finally, default graphics and color schemes can be replaced with custom ones tailored to the client's graphical identity.

--

Can a user see the selected authentication method(s) for a specific application?​

In the standard configuration, the user sees the list of available methods for providing the second factor, to which they have previously registered during logging into the application (importantly, only strong authentication methods based on FIDO2 can be combined). An additional option is the so-called User Dashboard, which can be enabled by the administrator of a given application representation. The User Dashboard allows not only viewing the used authentication factors but also approving, for example, additional keys added by the user. Broker administrators, in turn, have the ability to preview which authentication factors a particular user is using.

--

Does Secfense support one-time multi-factor authentication when traversing applications within SSO?​

Secfense UASB can add another authentication factor to applications that use SSO for primary authentication, such as Kerberos or NTLM protocols. In this case, additional layers of security can also be added in the form of Full Site Protection, Microauthorizations, or Trust Groups. Secfense IDP can be configured as a SAML service provider for both "on-premises" and SaaS applications, thus providing both "Single-Sign-On" functionality, secure login methods based on keys, and even full "Passwordless" capabilities.

--

Is the database in which user identities are stored relevant?​

Adding another authentication factor in Secfense UASB operates completely independently of the user database technology used by the protected application. We can integrate with RADIUS or OpenID to use these databases to add a second factor or with LDAP-based directories to import users into policies or remotely identify administrators. However, the authentication itself works on the principle of TOFU (Trust On First Use) and creates its own database of user logins.

--

Are we able to handle internal and external applications (those exposed to the Internet and those within the network)?​

The condition for adding another authentication factor through Secfense UASB is having some level of control over the network leading to the protected application. It doesn't matter whether the application is only available within the client's network or exposed to the Internet – if we can logically place the Broker somewhere between the user and the application, we can also secure that application. In the case of SaaS solutions where we obviously have no control over the network at the application, which we can secure, comes Secfense IDP, which as a SAML-based solution can secure any application that uses this protocol.

--

Which MFA methods can we support as standard?​

As standard, we support:

Authentication methods compliant with FIDO2/WebAuthn such as cryptographic keys, Apple Touch and Face ID, Windows Hello, passkeys (on all compatible devices), Convenient and also FIDO2-compliant Secfense Authenticator mobile application TOTP (Time-based One Time Passwords) - codes generated by any TOTP-compliant Authenticator application (Google, Microsoft, etc.) One-time codes sent via SMS (by the client's gateway or external one) One-time codes sent via email (by the client's service or external one) Authentication via RADIUS server Integration with Open-ID We are also open to new expectations or ideas.

--

Can Secfense UASB secure both applications located in a client-managed data center and applications provided as SaaS?​

To secure an application with Secfense UASB, the Broker must be logically placed between it and the user. This means that any application with its servers in a client-controlled data center can be secured in this way. In the case of applications provided as SaaS, an additional component comes into play in the form of Secfense IDP, which, thanks to integration with SAML and cooperation with the Broker, can not only handle authentication towards any IAM chosen by the client (or even several simultaneously) but also add additional values such as passwordless authentication or restrict access to applications to specific networks.

--

What user information does Secfense UASB collect?​

Secfense UASB only stores information necessary to conduct the authentication process using the second factor. In the basic deployment, this will be the login and some metric related to the selected second factor (public key for FIDO methods, seed for TOTP, phone number or email for those methods, etc.). None of this information allows impersonation of the user and "stealing" their second factor. For additional functionalities relying on information contained somewhere in the client's infrastructure (for example, LDAP integration to define opt-in users), Secfense UASB must, of course, store data related to the configuration of such integration. This data is encrypted.

--

Does Secfense UASB have an API for SIEM tools?​

All events are saved in the local Broker log and can be sent to a SIEM using the open remote syslog protocol.

--

Can Secfense UASB be added to existing automation-supporting tools (Angular-based applications, Ansible, etc.)?​

Secfense UASB exposes a full REST API that can be used to add policies to automation tools.

--

Which load balancers does Secfense UASB work with?​

The architecture and operation of the Broker make it independent of the type of load balancer present in the network. From the traffic perspective, it is simply another reverse proxy. So far, we have helped deploy on F5 BIG-IP, Netscaler, HAProxy, NginX, and KEMP Loadmaster – each of these technologies can handle traffic through Secfense Broker in a similar way, whether it's through content switching or health checking.

--

Does all network traffic have to go through UASB?​

As a rule, only the traffic directed to applications that the Broker is supposed to secure needs to pass through it. The system reads HTTP headers and processes only the traffic relevant from an authentication perspective; the rest is ignored by the Broker and passed through unchanged by the Proxy component. For some applications, it is possible to use a load balancer to forward only the relevant traffic to the Broker and direct the rest directly to the application servers.

--

Is it possible to use domain accounts to log in to the administrative panel?​

Secfense UASB can be integrated with an AD server to allow logging in with domain accounts. Furthermore, it is possible to assign administrators specific sets of permissions based on data from the AD server.

--

Does Secfense UASB send any data outside the internal network?​

In the basic configuration, Secfense UASB does not need to have access outside its network segment at all. Both FIDO2 standards and TOTP codes do not require any client-initiated connections to work. Additionally, the Broker never sends any data to the manufacturer's servers; even licensing and upgrades are done completely offline. We've made every effort to ensure that if any permissions on firewalls are needed, they only need to be granted to external servers. Under no circumstances does inbound traffic need to be opened.

--

How can the solution be scaled?​

Secfense UASB scales quite easily both vertically (scale-up) and horizontally (scale-out). In the former case, resources can be added to the virtual machine to handle a larger volume of traffic, while in the latter case, additional machines can simply be added for solution segmentation. In both cases, the Broker can be configured to work in a cluster, achieving not only redundancy but also (with the use of a load balancer) forcing devices to operate in Active/Active mode, doubling their throughput.

--

Is there a Bypass mechanism in case of device failure?​

Using a load balancer and health checks, rules can be configured to bypass the Secfense Broker in case of failure. Similarly, redundancy can be configured, and devices can be clustered in an Active/Standby mode, where one device handles traffic, and in case of its failure, the other can immediately take over these tasks. Finally, VRRP can be configured to provide Active/Standby operation even without using a load balancer.

--

In Active/Standby configuration, is it possible to seamlessly switch users to the second location?​

In a cluster configuration, both UASB devices share not only the configuration but also the private keys used for session management. The failure of one device and switching users to the other location will be completely imperceptible to them due to these shared keys.

--

Does Secfense UASB allow for configuring persistent sessions for users to avoid excessive prompting for the second authentication factor?​

In the standard configuration, after recognizing the user (when they successfully use their second authentication factor), Secfense UASB remembers them for 10 minutes. This means that during this time, when the user logs out again or is logged out of the application, they will not be prompted for their second factor when logging back into the application. This works based on the cookie lifetime in the browser.

Additionally, we can enable users to save their browsers. In this case, Secfense UASB collects over 200 metrics from the client's environment and saves them. For a defined period (typically 28 days), the user will not be prompted for the second factor when logging into a particular application from the saved environment.

Finally, we provide a functionality called Trust Groups, which allows connecting applications protected by Secfense UASB into logical trust groups. Successful use of the second authentication factor in one of the applications means that the user will not be asked for it in other applications from the group for a defined period.

All the above-mentioned metrics are fully configurable by administrators.