1. Overview

“Azure AD Connector” is a DNN provider that will outsource identity management from DNN to the Azure Active Directory (cloud service). Basically it will keep DotNetNuke user accounts in the Azure AD system, also all tasks related to manage these accounts could be done from the Azure AD level. This will create an scenario where DNN will be only accessing these accounts.

Azure AD can work as a identity container for almost three thousands apps and for all these apps Azure will provide one single identity. For example if company employee works with Salesforce, Office 365, Gmail and DNN, now he can use only one identity (the same username and password) for all these services.

1.1. What is the problem

As the number of SaaS apps (Office 365, DNN, Box, Salesforce) grows, it becomes challenging for the corporate administrators and employees to manage accounts and access rights.

For example if company employee works with: Office 365, DNN and Salesforce, he has to remember three sets of different credentials (username and password). In practise, for simplify he’s using same username and passwords for all accounts, which creates security hole.

On the other hand corporate administrator must keep an eye on all these identities, what creates extra work and is less secure.

1.2. Solution - a Big Picture

We are offering a solution that allows add DNN website to the Azure Active Directory ecosystem, like on figure below.

_images/big-picture_01.png

In this approach client applications (O365, Salesforce, DNN) are not gathering user credentials and they don’t manage user credentials. They don’t have to handle password resets, multi-factor auth and so on.

SaaS apps rely on Azure AD that is responsible to deliver these identities in compliance with the industry’s best practices. In that case one set of identity credentials can be reused across all SaaS apps. And that’s just a few advantages if you want know more please read chapter below.

1.3. Benefits

Below are described most important advantages of scenario where identities are stored in Azure AD (Microsoft Azure Active Directory).

  1. Users can use their primary organizational accounts to sign in to DNN. Now one user identity allows sign in to: on premise Active Directory, Office 365, DNN, Salesforce, and more that 2700 other apps.
  2. If your DNN will become compromised or something bad happens, your user credentials are safe. It’s because DNN is no longer responsible for authenticating users and storing user accounts and passwords, user passwords are never stored on DNN web server. DNN will hold only copy of the user profile.
  3. Azure Active Directory can be easily integrated with other cloud applications. If your employees works with apps like Salesforce, Office 365 and now with DNN. They will use only one identity (one user name and one password) for all these apps. Employees are more productive when they have a single username and password to remember.
  4. At the sign in process AD user profile is copied to DNN website data store.
  5. User can enjoy Seamless Single Sign-on (Seamless SSO), this mean user doesn’t needs to go through login process for each SaaS app. If the user sign-in is successful, he’s able to access all SaaS applications, without entering username and pasword again.
  6. Resetting a forgotten password or requesting access to an application without waiting for assistance from the helpdesk. This is done through Azure AD self-service password reset (SSPR) feature. Everything is happening on Azure side and DNN system is not involved in that process.
  7. Password protection and the custom banned password list, helps guarantee that users are following best practise guidance. Make sure that users doesn’t using common passwords or passwords that are known to be included in recent data, more info
  8. Azure Active Directory reporting that helps determine how DNN and other apps and services are utilized by your users. This helps detect potential risks affecting the health of your environment. Troubleshoot issues preventing your users from getting their work done. For example reporting services informs about sign-in activities, risky sign-in (sign in after multiple failures), sign in from multiple geographies, sign in from unknown sources and many more, see Microsoft reference
  9. Conditional access, it’s a capability that enables you to define conditions under which authorized users can access DNN and other SaaS apps, for example in easily way you can force multi-factor authentication for users from specified group, see here
  10. Multi Factor Authentication (MFA), you can quickly configure list of users that needs MFA. Second authentication factor, that will verify user can by: an automated phone call or a text message.
  11. Restrict access for mobile devices that doesn’t meet company standards for security and compliance, more
  12. Additionally you have centralized view of your user access to the all apps.
  13. You can provisioning and de-provisioning users into the DNN website, directly from Windows Server Active Directory and/or Azure AD. This feature will be implemented in the future.

1.3.1. Basics of authentication

  1. Azure AD is the identity provider, responsible for verifying the identity of users and applications that exist in an organization’s directory, and ultimately issuing security tokens upon successful authentication of those users and applications.
  2. An application that wants to outsource authentication to Azure AD must be registered in Azure AD, which registers and uniquely identifies the app in the directory.
  3. Once a user has been authenticated, the application must validate the user’s security token to ensure that authentication was successful.
  4. The flow of requests and responses for the authentication process is determined by the authentication protocol that was used, such as OAuth 2.0, OpenID Connect.

Reference:

* https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios

1.4. Technology Stack

“Azure AD Connector” is using:

  1. OAuth 2.0 - authorization protocol that defines communication between DNN and “Azure AD”.
  2. “OpenID Connect” that extends “OAuth 2.0” by providing an identity layer.
  3. “Microsoft Graph” (https://graph.microsoft.com endpoint) to access Azure Active Directory resources like: user profile and groups.
  4. OWIN stack that is implemented in DNN website.

1.5. Azure AD v2.0 limitations

“Azure AD v2.0” is newer than “Azure AD” and features are still being added, there are some limitations with the v2.0 endpoint that you need to factor into your decision. For example:

  1. Some features may not yet be fully implemented in v2.0. For example, your app might not work if your enterprise customer turns on enterprise mobility security features like conditional device access.
  2. You cannot call Microsoft Graph from a standalone web API.
  3. You cannot call Cloud Solution provider apps.
  4. Windows integrated authentication for federated tenants is not supported. This means that users of federated Azure AD tenants cannot silently authenticate with their on-premises Active Directory instance. They will have to re-enter their credentials.

For more information about differences between the Azure AD v2.0 endpoint and the Azure AD endpoint, see: