Application Builder

Open Authentication (OAuth) allows secure Single Sign-On in distributed cloud infrastructure. For example, you may build a collection of business applications that use Azure Active Directory to manage users. Individual applications do not store original user information and instead rely on Azure Active Directory to manage users, control sign-in, as well as offer password recovery, suspicious activity detection, and general account security. In this example, each custom application is registered with Microsoft Graph and maintains it’s own configuration settings to delegate user sign-in to Azure Active Directory.

Delegated security speeds up your application development while conforming to high standards of account management and protection.

Release 8.6.6.0 of Code On Time web app generator now offers an easy way to register authentication handlers for Google, Facebook, Windows Live, Identity Server, Microsoft Graph, SharePoint, DotNetNuke, and upcoming Cloud Identity (replacement for ASP.NET Membership in applications built with Code On Time).

The dynamic nature of OAuth configuration requires a place to store settings in the application. Make sure to enable the Content Management System in the database of your app. Log in as admin to your app, and navigate to Site Content.

Click on the plus (+) button and a form will ask the type of content the user wishes to create. Two options are available – (custom) and Open Authentication Registration. Future releases will allow creating access control lists, custom pages, data controllers, user profile images, workflow register entries, etc. Developers will be able to create editors for custom content items in their applications.

Choose “Open Authentication Registration” option and press OK. Select the Authentication provider from the list of available options in the Open Authentication Registration form, and additional configuration parameters will be displayed.

Enter the required properties and press “Save” to register the provider.

The new registration record will be displayed in the Site Content. Selecting an existing OAuth registration will reopen the Open Authentication Registration form.

User Synchronization

When clients complete authentication with an external provider, the provider returns a username to the app. If a user account is found with a matching username in the application database, then the client is logged in as that user. If the matching user account is not found, what will happen next is determined by the provider configuration. If “Synchronize users” is enabled, a user account will be created with that username and randomly generated password and password answer. If the “Synchronize users” property is disabled, then the user is denied access to the application.

Most of the time, you will want to enable user synchronization to create “shadow” user accounts in your application database automatically. Shadow user accounts are representations of the external user identity in the application database. Changes made to these accounts will not affect the identity configuration managed by authentication provider. These accounts represent a cached user name and email. The user password, contact, and identity recovery information is not stored in the application data. If the user is deleted or renamed, then only the cached data is changed. Next sign-in authenticated by the provider will create another shadow user account.

If synchronization of users is disabled, then you will need to create user accounts ahead of time. The passwords assigned to these accounts do not need to be known to the users. Successful authentication by a registered external provider will log in the user with a matching name to the app.

Many applications save references to users in special columns (for example: Modified, Created, ApprovedBy, Owner, DeletedBy, etc). If authentication provider is enabled, then references to shadow user accounts will be recorded.

User Role Synchronization

Many OAuth providers maintain user roles. When a user is authenticated by an external provider, the provider may return a list of roles or groups assigned to that user. If “Synchronize user roles” is enabled for that authentication provider, then the reported user roles will be assigned to the user. Any shadow user roles assigned to the shadow user but not matched by the provider will be removed.

Requesting a list of user roles requires adding a system account to the provider registration. The system account must have permission to access the roles or groups of authenticated users.

If “Synchronize user roles” is enabled, press ADD SYSTEM ACCOUNT to save the registration record. You will be redirected to the authentication provider to acquire permission to read user roles.

If authentication is successful, the provider will redirect back to the Site Content page and update the registration record with system access tokens. The application will use the system access token to obtain shadow user roles from the authentication provider on each successful login. Access tokens do expire periodically and will need to be renewed. Simply select the provider registration and click Add System Account.

Auto Login

If only one authentication provider is used to confirm user identities, then consider enabling “Force users to login with this provider”. If an anonymous user tries to access this application, then the app will immediately redirect to the authentication provider for sign in. This will also happen if the user logs out.

To access the system login form and sign in with an internal user account, append “?_autoLogin=false” to the URL of the page in your browser.

Redirect Uri and Local Redirect Uri

The Redirect Uri property determines the address that the provider will return to after a user has been authenticated. For providers that support defining more than one Redirect Uri, the Local Redirect Uri property will be passed to the provider when the app is running in “local mode”. This automatic switching makes it easy for developers to test the authentication pipeline on a development machine, without having to publish the app.

Simply type in the address of your site (myapp.azurewebsites.net), and it will be expanded to the correct full URL (https://myapp.azurewebsites.net/appservices/saas/[ProviderName]).

Facebook

To create a registration for OAuth integration with Facebook, the properties Client Id, Client Secret, and Redirect Uri must be specified. Client ID and Client Secret can be obtained from the Facebook Developer Dashboard. Synchronization of roles is not supported.

Google

The Google Developer Dashboard will provide the Client Id, and allow developers to generate a Client Secret. Adding system account also allows storing blob data in Google Drive by configuring the Google Drive Blob Adapter.

Windows Live

The Microsoft Apps Dashboard allows creating new clients and secrets. Role synchronization is not supported.

Microsoft Graph

The Client Id and Client Secret values can be created from the Microsoft Apps Dashboard. The Microsoft Graph OAuth provider allows users to authenticate with their Windows Live, Office 365, Azure Active Directory, or SharePoint Online accounts. The Tenant ID property controls the source of external accounts. Specify the value “common” to allow all sources. Enter the specific Tenant ID of your tenant to restrict access to the app to only those accounts registered in the specific tenancy.

If “Synchronize user roles” is enabled, be sure to press Add System Account to grant your app access to the roles or groups of the tenancy.

SharePoint

The Client Id and Client Secret properties can be acquired by navigating to “https://mysite.sharepoint.com/_layouts/15/AppRegNew.aspx”. Make sure to replace the root with your SharePoint site URL. The Client Uri property is equal to “mysite.sharepoint.com” if you are connecting to SharePoint Online.

When configuration is complete, be sure to press Add System Account to allow the app access to the SharePoint groups of each user that authenticates with your app. This also enables storing blobs in SharePoint file system via the SharePoint Blob Adapter and creating “service” data controllers from SharePoint lists in your site.

DotNetNuke

Configuring a DotNetNuke portal as an authentication provider requires installation of Cloud On Time Connector for DotNetNuke. Specify the authentication endpoint in the Client Uri property. Define a comma-separated list of tokens in the Tokens property. These tokens will be persisted to the SiteContent table for each user. These tokens can be accessed by calling @Profile_Token_Name in SQL business rules or GetProperty(“Token_Name”) in code business rules, replacing the colon (:) with an underscore (_).

Identity Server

Be sure to consult the documentation of your Identity Server installation on how to configure authentication clients.

Starting with release 8.6.6.0, apps created with any edition of Code On Time generator can be integrated with external DotNetNuke websites with the help of Cloud On Time Connector for DotNetNuke.

Cloud On Time Connector for DotNetNuke is a ready-to-deploy module that provides OAuth 2.0 endpoints for any number of external apps created with Code On Time. It also enables application data presentation/links within the portal pages. Utilize the power of Code On Time to rapidly build database applications integrated with DotNetNuke.

Users will also have the ability to “Login with DotNetNuke”, and use their existing DotNetNuke accounts in the Code On Time app.

The instructions below will use the Northwind sample and a fresh instance of DNN 9.0.2 hosted on Microsoft Azure.

Make sure to enable Content Management System for the database of your app. 

Installing Cloud On Time Connector for DotNetNuke module

The next step is to install the Cloud On Time Connector for DotNetNuke module into your DNN portal instance. Download the latest release of the module from the Releases page.

Using your preferred browser, navigate to your DNN portal and sign in with a SuperUser account.

In the sidebar, hover over the gear icon and press “Extensions”.

At the top of the Extensions panel, press “Install Extension”.

Upload the zip file containing the Cloud On Time Connector for DotNetNuke module.

Press “Next” to confirm the package information, and press “Next” again to confirm reviewing the release notes. Accept the license, and press “Next” one more time to begin installation.

Once installation is complete, the installation report will be displayed.

The module is now installed in your DotNetNuke instance.  Note that the website will restart, which may cause some delay immediately after installation.

Configuring Authentication Endpoint

Cloud On Time Connector for DotNetNuke can integrate any number of external applications into your DotNetNuke portal. An endpoint page with an instance of the module will need to be created in the portal for each integrated application. The developer must configure the Code On Time app and the module instance on the portal page with matching parameters to enable communications over OAuth 2.0 protocol.

First, let’s create a publicly-accessible endpoint page.  Under the “Content” icon in the sidebar, select the “Pages” option.

In the top right corner of the Pages panel, press “Add Page”.

Specify the following properties:

The name and URL provided above are for demonstration purposes only. You can choose any name and URL that you like.

Under the Permissions tab, check the box to allow all users to view tab. This will enable both anonymous and authenticated users to access the page.

Press “Add Page”. On the next screen, drag the page to the end of the page list.

The browser will then redirect to the page in edit mode. In the bottom-left corner, press the “Add Module” button.

From the Add Module screen, click on “Cloud On Time Connector”.

Drag the floating module and drop on the first dashed placeholder in the end-point-app1 page.

Mouse over the top right corner of the module instance on the page to reveal the control bar.  Mouse over the gear icon, and press “Settings” in the hover menu.

Switch to the “Configuration” tab. Use the following settings:

When configuration is complete, press “Update” to save your changes. Now the module instance on the page end-point-app1 has been configured to accept authentication connections.

We will need to configure the app created with Code On Time to request authentication connections to the DotNetNuke portal.

Navigate to your app, login as admin, and switch to the Site Content page. Press the Plus icon to create a new record.

Select “Open Authentication Registration”, and press OK.

Configure the following:

Your configuration should look like the one below:

Press the checkmark icon to save the new record. Your app is now configured for authentication connections with DotNetNuke portal.

To test the connection, log out of your app.

Once logged out, your app will show the login form. Notice that a new action “LOGIN WITH DOTNETNUKE” is now available.

Push the new action, and you will be navigated to your DotNetNuke portal. If you are not signed into your portal, the login page will be displayed.

After user has logged in, the login page will redirect to the authentication endpoint. If there are no issues with the configuration, the portal and app will communicate over OAuth2.0 protocol. A user account will be created in the app membership database with the DotNetNuke username, email, roles, picture, and random password. If tokens were requested in the configuration of the app, then the values will be captured by the application.

If the Account Manager is enabled in the application, subsequent logins will not authenticate with DotNetNuke portal again until the user logs out. You can add “Auto Login: true” parameter to the sys/saas/dnn entry in the SiteContent table to automatically redirect unauthenticated users to DotNetNuke.

If you have developed multiple applications, then create additional authentication endpoint pages following the instructions above for each app. Note that your apps can be deployed anywhere and do not need to physically reside on the same server as the DotNetNuke portal.

Data Presentation in DNN Portal

The Cloud On Time Connector for DotNetNuke module also allows displaying data from your application directly in the portal pages.

Navigate to your DotNetNuke portal with the configured application endpoint as a SuperUser account.

Hover over the Content icon on the sidebar, and press “Pages”.

In the top right corner of the Pages panel, press “Add Page”.

Specify the following properties:

Switch to the Permissions tab, and check the box to allow registered users to view tab.

Press “Add Page”. On the next screen, drag to place the new page after the Home page.

You will be navigated to the new Products page. In the bottom left corner, press “Add Module”.

Select the “Cloud On Time Connector” module from the list.

Drag the floating module and drop on the first dashed area in the page.

Hover over the gear icon above the module, and press “Settings”.

Switch to the Configuration tab. If the authentication endpoint has already been configured, then the Mode property of this module instance will be set to “Data Presentation”. Enter the following:

Press “Update” to save your changes. Proceed to refresh the page. The module will now display a grid of products.

Accessing User Tokens

If tokens were configured for both sys/saas/dnn entry and the authentication endpoint of DotNetNuke portal, then the values can be used in the implementation of business rules in the application. For example, token “User:DisplayName” can be accessed by the following sample code:

SQL:

set @Result_ShowAlert = 'Hello ' + @Profile_User_DisplayName

C#:

Result.ShowAlert("Hello " + Convert.ToString(GetProperty("Profile_User_DisplayName")));

Visual Basic:

Result.ShowAlert("Hello " & Convert.ToString(GetProperty("Profile_User_DisplayName")))