Quino provides support for providing and obtaining identities to use in an application (e.g. with
There are several services that work together to provide groups of services.
The basic services let an application create the .NET
IPrincipal objects in a standardized way.
IIdentityFactorycreates identites for names. The standard implementation uses an
IIdentityValidatorto create identities only when the application considers a name to be valid.
IPrincipalFactorycreates principals for identities.
IAnonymousIdentityFactorycreates anonymous (non-authenticated) identities
An application uses the validator both to determine whether a given username is considered valid and to normalize that username if it is. The standard behavior supports simple usernames (e.g. "Bob") and also users in Windows domains (e.g. "Encodo\Bob").
IIdentityValidatorallows an application to determine whether a given name can be normalized. The standard implementation uses the
IIdentityValidatorSettingsto control how to filter and format local and domain users.
IIdentityValidatorSettingsallow the application to indicate that it has a
RestrictedDomain. If this value is set, then the application allows simple usernames and also users from that domain. If it is not set, then all domains are allowed. Use
StripDomainto control whether the normalized identity name includes the domain.
The operator is the system user that started the application. An application has access to this identity, as well.
IOperatorIdentityProviderprovides the identity of the user that started the application. If Windows-specific assemblies are used, then the
The current user is the user considered by the a single-process application to be the logged-in user. This is applicable to single-user applications like desktop or console applications. A web application bases its notion of current user on the authentication data including in a given request.
ICurrentUserIdentityFactorycreates the identity for the logged-in user of the application (this can differ from the identity returned by the
ILoginSettings.Behavior (e.g. by calling
UseBehavior() in application configuration) to determine how this user is initialized by the
IIdentityUniqueIdentifierExtractorgets a unique identifier from an identity, if possible. The default implementation does nothing; the
WindowsIdentityUniqueIdentifierExtractorcan work with
WindowsIdentityobjects to get the secure identifier from it.
IIdentityUniqueIdentifierCalculatorbuilds on the extractor to implement an algorithm for looking up the unique identifier.
The standard algorithm for calculating a unique identifier is to do the following:
- Given an identity
IIdentityUniqueIdentifierExtractorto try to get
- If it worked, return
- Otherwise, use the
- If the
oto the same username, then try to get
- If it works, return
Desktop applications deployed to a company network will generally want to set the
IIdentityValidatorSettings.RestrictedDomain to the company's domain name. If the domain must be configurable, an application can read the settings from the configuration file, as described in Settings.
An application is also free to provide custom logic with its own
WindowsIdentity (Single Sign-on)
Applications can use the
Quino.Security.Windows.Core assembly to integrate the
WindowsIdentity as the operator. This assembly provides the following two classes:
WindowsIdentityUniqueIdentifierExtractorknows how to extract the unique identifier from a
When these two classes are registered, the standard algorithm for the
IIdentityUniqueIdentifierCalculator works as expected for single-signo