Thrown when a credential validation fails during IAuthenticationProvider.Authenticate
Implements IAuthenticationProvider using a database
Holds the bitmask of permissions for a profile
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.
Helper function for generating a one-way hash from a string.
Defines a user profile
A collection of ProfileInfo objects
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).
Thrown when a user token has aged and cannot be restored from database
After authentication, the UserContext object holds the current user identity and a collection of profiles.
Simple string collection of user profile names.
WindowsAuthenticationProvider implements IAuthenticationProvider for ActiveDirectory and NTLM. Not generally appropriate for use in SaaS and other applications with non-employee users.
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:
Option for handling of caching user credentials during login
Attributes for a user profile
Attributes that control basic security behavior for the default database provider.
Attributes that apply to a user that is loaded from the default database provider.
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.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.
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.
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.