NetQuarry supports application security using a powerful, replaceable set of authentication and permission patterns. Depending on the needs of your application and the capabilities of your enterprise infrastructure, NetQuarry can support several different methods of user authentication.

Authentication Providers (IAuthenticationProvider)

An authentication provider implements the IAuthenticationProvider interface and handles the Authenticate method. NetQuarry ships with three providers, a Generic provider, a Windows based provider (for Active Directory or NTLM authentication), and a database provider.

Roles and Profiles

After authentication, the platform asks the authentication provider for a list of directory (ADS, NTLM, Database) roles for which the user is a member. These directory roles are mapped to runtime “profiles” which assign all runtime objects permissions. By default, an object is available to all users. The mapping of directory roles to profiles is done using the NetQuarry studio.
At runtime, the platform calls IAppContext.HasPermission to determine if an object is available to the current user.


Most objects use the NetQuarry.ObjectPermissions enumeration to specify security for that object. The NetQuarry.ObjectPermissions enumeration is a superset of all possible system permissions (and is extensible). All attributes of the enumeration don’t apply to every object. For example, NavigationTargets only support the “Read” permission bit.


For permissions that cannot be expressed as NetQuarry.ObjectPermissions bits, you can define a custom “policy.” A policy is simply a named permission that is granted to a set of profiles. This is a powerful and handy method for building an application with specific permissions for your users.
For example, one could define a policy that grants a set of profiles the right to mass email to the contents of a list of data. Then, before adding the custom MapperCommand that supported this functionality, the developer would ask the application if the current user had permission to the policy.


After authentication, the UserContext object holds the current user identity and a collection of profiles. A UserContext object can re-create itself from a token securely. The IAppContext object holds the current UserContext.