You can add the ASP.NET Identity package to an MDriven Turnkey model to support user registration, sign-in, user roles, external logins, and access to the authenticated user from your model.

File:AspNetIdentity.zip.

When to use this package

Use this package when your Turnkey application needs its own user accounts and you want the application to identify the current signed-in user in the model.

The package follows the SysUserAuthentication pattern. It uses the ASP.NET Core Identity architecture for:

• Authentication — establishing who the user is when they sign in.
• Authorization — deciding what that user may view, enable, or change.
• Local user names and password hashes.
• User roles and external-login information.
• A model-level reference to the current user.

For example, an administrator-only action can test whether the current user is an administrator before it is shown or enabled.

Add the package to your model

The supported way to add the authentication pattern is to merge it into your model from TK Live View.

1. Open your model in MDriven Designer.
2. In TK Live View, merge the SysUserAuthentication pattern into the model.
3. Review the added model elements before changing them. The pattern relies on its expected class and member names so that Turnkey can recognize it.
4. Upload the updated model to Turnkey.
5. Test registration and sign-in in the deployed application.

You can keep the added elements in a separate package to make it clear which model elements came from the authentication pattern. A package is an organizational container, comparable to a namespace. This organization is optional; moving elements between packages does not replace the need to preserve the pattern's required names.

What is added

The package supplies the model structures that Turnkey expects for ASP.NET Identity. The central classes are described in SysUserAuthentication:

Model element	Purpose	Example
SysUser	Represents an application user, including a unique user name, password hash, security stamp, and administrator flag.	A user named alex@example.com signs in; the corresponding SysUser is the current user.
SysExternalLogin	Holds information for a third-party login associated with a user.	A user who signs in through Google has an external-login record associated with their SysUser.
SysRole	Represents a user role that can be used with access groups.	A role such as Administrators can be used to control administrative ViewModels and actions.
SysSingleton	Provides model access to the current authenticated user.	An expression can start from SysSingleton.oclSingleton.CurrentUser to inspect the signed-in user.

Use the current user in model expressions

A singleton is a class intended to have one object instance. In this pattern, SysSingleton has a derived association to CurrentUser. OCL provides the oclSingleton operator to obtain that instance.

For example, the following expression checks whether the current user is an administrator:

SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

Use such expressions in ViewModel column visibility and enablement, actions, and derived attributes where appropriate. For rules that apply to several actions or ViewModels, define an access group instead of repeating the same expression. Security explains how to use the current user and access groups to centralize these rules.

Password handling

Do not assign a plain-text password to PasswordHash. The SysUser pattern provides HashPassword(pwd:String) and SetPassword(pwd:String) so that a new password is stored as a password hash.

For example, a password-change flow should call SetPassword with the user's new password rather than writing directly to PasswordHash.

The SecurityStamp is used to invalidate sessions and cookies when a user resets a password or adds an external login.

Add password reset separately

The ASP.NET Identity package does not by itself provide password-reset pages and email processing. To add that workflow, merge the Password Reset Package after the authentication pattern is in place.

The password-reset package extends the model with reset tickets, reset pages, and a server-side ViewModel that sends reset emails. You must configure email settings on the MDrivenServer and update the sender expression in that package before using it.

External sign-in and other authentication approaches

The pattern supports external login records for providers such as Google, OpenID, Microsoft, and Facebook. Configure the selected provider according to the relevant integration guidance.

If another system already authenticates your users, evaluate that approach before adding local credentials. Related options include header-based authentication and single sign-on. The Integration section lists authentication and security integration topics.

Verify the deployment

After uploading the model to Turnkey:

1. Confirm that the deployment has evolved the database for the added authentication classes.
2. Open the application and verify that a user can register or sign in.
3. Confirm that SysSingleton.oclSingleton.CurrentUser resolves to the signed-in user in a ViewModel expression.
4. Test one restricted action or ViewModel with an administrator and a non-administrator account.
5. If you add password reset, verify email-server settings and test both a valid and an expired reset ticket.

See also

• Documentation:SysUserAuthentication
• Documentation:TurnkeyUserLogin
• Documentation:Password Reset Package
• Training:Security
• Documentation:Integration

Configure external sign-in securely

You can configure an OpenID Connect identity provider for a Turnkey application when users authenticate outside the application and Turnkey must create or update the corresponding SysUser.

OpenID Connect uses an identity provider (IDP) to return the user to Turnkey after sign-in. The IDP redirects to the configured callback URL with a code; Turnkey then accepts the user and creates or updates SysUser, SysUserClaims, and the claims received from the provider.

Require HTTPS

Configure the Turnkey site to use https. For an on-premise deployment, configure IIS with an HTTPS certificate; HTTPS is required for the internal WCF communication in MDriven Turnkey. See Set up MDriven Turnkey on premise.

Use the same HTTPS URL when registering callback URLs with the IDP. For example, an OpenID Connect callback can be:

<OpenIDConnectRedirectUrl>https://YourTurnkeyURL/signin-oidc</OpenIDConnectRedirectUrl>

The callback URL must be on the IDP's allowed redirect list. Register separate callback URLs for local development, test, and production when those environments use different URLs.

Store provider configuration outside upgrade files

Place OpenID Connect settings in App_Data/TurnkeySettings.xml, a TurnkeySettingsExtra file, or TurnkeySettingsOverride.xml. Use TurnkeySettingsOverride.xml when you need settings to remain separate from a TurnkeySettings.xml file supplied by an upgraded Turnkey version.

The following example shows the documented settings for an OpenID Connect provider. Replace every placeholder before deployment.

<OpenID_ClientId>yourid</OpenID_ClientId>
<OpenID_Authority>youridpserver</OpenID_Authority>
<OpenIDConnectRedirectUrl>https://YourTurnkeyURL/signin-oidc</OpenIDConnectRedirectUrl>
<OpenIDConnectResponseType>code id_token</OpenIDConnectResponseType>
<OpenIDConnectAppSecret>AppSecret</OpenIDConnectAppSecret>
<OpenID_TokenEndPoint>yourserverTokenEndpointUsuallyEndsLikeThis/oauth2/v2.0/token</OpenID_TokenEndPoint>
<OpenIDConnectScope>offline_access openid profile</OpenIDConnectScope>
<SharedSecret>Secret</SharedSecret>

Treat OpenIDConnectAppSecret and SharedSecret as sensitive configuration values. The SharedSecret encrypts tokens stored in the database in SysToken. Do not enable ShowPII unless you intend to log personally identifiable information in clear text.

Request refresh tokens when required

Request openid and, when needed, profile in OpenIDConnectScope. To obtain a refresh token that the server can use to request a new access token after the initial authorization, include offline_access:

<OpenIDConnectScope>offline_access openid profile</OpenIDConnectScope>

For Azure AD access and refresh tokens, configure OpenID_TokenEndPoint and include offline_access. Use code id_token as the response type at minimum. Adding token, as in code id_token token, also returns an access token; Turnkey reads its claims and adds them to the user together with claims from the ID token.

Configure provider-specific callbacks

Use the callback suffix required by the selected provider. For example, Google uses /signin-google and Microsoft uses /signin-microsoft. Copy the client ID and client secret into the Turnkey portal, save the change, and select Send Settings and Restart to apply Google or Microsoft authentication settings. See External login services in MDriven Turnkey.

For Amazon Cognito, configure the callback URL as https://YourTurnkeyURL/Account/AWSCognito and configure the same URL as the Cognito callback URL. The Cognito sign-out URL is the Turnkey URL.

Verify the sign-in flow

1. Register the exact HTTPS callback URL with the IDP.
2. Sign in with a test provider account.
3. Confirm that Turnkey creates or updates the user's SysUser and associated claims.
4. Confirm that SysSingleton.oclSingleton.CurrentUser resolves to that user in a ViewModel expression.
5. If refresh tokens are required, confirm that the IDP grants offline_access and that the configured token endpoint is correct.

See also

• Documentation:OpenID config
• Documentation:External login services in MDriven Turnkey
• Documentation:SysUserAuthentication
• Training:Security