Active Directory Federation Services (ADFS) is a component in Microsoft® Windows Server™ 2003 R2 (or higher versions) that provides authentication technologies. In details it allows authenticate to a web application using corporate credentials.
To connect DNN with AD FS a special DNN provider is required that will create federation between DNN and Active Directory. After that DNN membership will rely on AD FS as an authorization backend. This document will show how to configure DNN that can take advantage of using AD FS.
AD FS is an identity mechanism that allows access for people that are outside of the corporate boundary. In the secure way Active Directory resources (like identities) can be exposed for web apps, that are hosted somewhere in the Internet.
One of the possible scenario is described below. There is an on-premise Active Directory placed in the corporate Intranet, and there are web apps, hosted outside of the corporate. Web apps are in Internet whereby access to these apps is opened for all. The point is if someone want’s to sign in to that app, his credentials are validated against the AD user store and this validation is happened in secure manner.
Solution described in this document is targeted to:
Use case - Company Blog
Blogs are valuable marketing tool for companies. Blogs can educate customers, build trust, and even bring in new leads. Let say that we have big company. Company has employees whose identities are located in the Active Directory. It’s an on-premise Active Directory system and access from the Internet is protected by the firewall. Security is very important for that company.
Company want’s to have a blog. Blog will be for employees, customers and potential clients. Corporate admin doesn’t want to create new accounts for users who needs add blog posts or blog comments. On the other hand employees doesn't want to have another username and password just for using company blog.
Solution must meet following requirements:
easy to maintain,
accessible from corporate Intranet and from Internet (outside of the office),
accessible from mobile devices (mobile friendly),
To achieve all these goals we can create solution described on the figure below.
We have DNN that is hosted outside of the company. DNN has an blog plugin. All users employees/customers have access to that blog. Additionally corporate employees using their actual identities can sign-in to DNN and add content to the blog (posts or comments).
What is most important: corporate admin doesn’t need to create any new accounts on the DNN for users that want’s to add blogs, posts or comments.
CMS integrated with employees
From a company perspective, in just a few steps you can install vanila CMS, where company users can sign-in using their current credentials. There is no need to create new username/password for employees.
“ADFS-Pro Authentication” give you ability to outsource authentication process from DNN to the Active Directory. Additionally authentication can be outsourced to any other security token service (STS) that is using the WS-Federation protocol like: Microsoft Azure Access Control Service (ACS), Identity Server, IBM Tivoli, etc.
ADFS can be configured to use with external authentication providers. This gives you ability to add second authentication factor, for example security code from mobile message. This will dramatically improves DNN security. For more information about additional authentication methods click here.
New authentication mechanisms
IT administrator can choose what authentication methods are used for DNN, based on the network location from which they access protected resources. For example administrator can mandate the use of more secure authentication methods for access requests from the extranet.
They can also enable device authentication for seamless second-factor authentication. This ties the user’s identity to the registered device that is used to access the resource, thus offering more secure compound identity verification before protected resources are accessed.
One set of credentials
Corporate employees use a single set of credentials across all applications that they are using. One credential set to access: DNN, Salesforce, Office 365, etc.
Take away responsibility from DNN
DNN application that is using AD FS, is no longer responsible for the following:
authenticating users, the authentication process is outsourced to external system like AD FS,
storing user accounts and passwords, credentials are stored in Active Directory,
integrating with other identity systems from other platforms or companies;
Additional Identity Providers
ADFS requires users to have an account in Active Directory or in one of the Identity Provider (IdP) that ADFS trusts. However, users may have no access to an Active Directory, but have accounts with other well-known IdP. These issuers typically are social networks and email providers. In this approach you can sign in to DNN using Facebook, Google or Windows Live account. For that scenarios an Microsoft Azure™ Access Control Service (ACS) must be implemented.
To implement solution described in this document you need:
DNN v7.3.4, or higher.
DNN website must support https protocol.
Modern web browser with enabled Java Script and cookies.
Active Directory with installed AD FS service.
- DNN provider that consumes WS-Federation protocol, for example: ADFS-Pro Authentication.
ADFS-Pro Authentication - DNN plugin that allows you connect DNN to AD FS
DNN&ADFS - User Guide that describes implementation details