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.

Classes

  ClassDescription
Public classAuthenticationException
Thrown when a credential validation fails during IAuthenticationProvider.Authenticate
Public classDatabaseAuthenticationProvider
Implements IAuthenticationProvider using a database
Public classDefaultPermissions
Holds the bitmask of permissions for a profile
Public classGenericAuthenticationProvider
Base class for implementing an authentication provider. When used as the authentication provider itself (rather than as a base class for the authentication provider), always authenticates the user regardless of password. To use, derive from this class and override the OnAuthenticate(String, String, NameValueCollection, Int64) method.
Public classHash
Helper function for generating a one-way hash from a string.

Examples

 Copy imageCopy
string sensitiveData = "123456789";
mapper.Fields["external_id"].Value = NetQuarry.Security.Hash.ToSHA256(sensitiveData, "1PUnrmSiicHQLl+S3nOaWnivmjk=");
Public classProfileInfo
Defines a user profile
Public classProfileInfos
A collection of ProfileInfo objects
Public classRandomPassword
This class can generate random passwords, which do not include ambiguous characters, such as I, l, and 1. The generated password will be made of 7-bit ASCII symbols. Every four characters will include one lower case character, one upper case character, one number, and one special symbol (such as '%') in a random order. The password will always start with an alpha-numeric character; it will not start with a special symbol (we do this because some back-end systems do not like certain special characters in the first position).
Public classTokenExpiredException
Thrown when a user token has aged and cannot be restored from database
Public classUserContext
After authentication, the UserContext object holds the current user identity and a collection of profiles.
Public classUserProfiles
Simple string collection of user profile names.
Public classWindowsAuthenticationProvider
WindowsAuthenticationProvider implements IAuthenticationProvider for ActiveDirectory and NTLM. Not generally appropriate for use in SaaS and other applications with non-employee users.

Interfaces

  InterfaceDescription
Public interfaceIAuthenticationProvider
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. Several standard authentication provider are available:
  • DatabaseAuthenticationProvider - Authenticates users based on user ID and password stored in the main operational database. This is the primary authenticator.
  • GenericAuthenticationProvider - Always authenticates the user regardless of password. Also serves as a base class for most other authentication provider implementations.
  • WindowsAuthenticationProvider - Authenticates using the company's ActiveDirectory and NTLM. Not generally appropriate for use in SaaS and other applications with non-employee users.

Enumerations

  EnumerationDescription
Public enumerationCredentialsCacheOption
Option for handling of caching user credentials during login
Public enumerationProfileAttrs
Attributes for a user profile
Public enumerationSecurityAttributes
Attributes that control basic security behavior for the default database provider.
Public enumerationUserAttrs
Attributes that apply to a user that is loaded from the default database provider.

Remarks

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.

Permissions

Most objects use the NetQuarry.Security.ObjectPermissions enumeration to specify security for that object. The NetQuarry.Security.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.

Policies

For permissions that cannot be expressed as NetQuarry.Security.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.

UserContext

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.