Rules

Authentication and authorization are complicated, and it is risky to try and implement them yourself. Use this rule as a guide on choosing the right service or framework for your situation.

Choosing the right authentication and authorization approach for your situation can be tricky. It is a multi-faceted problem with many variables, and what seems like the right choice in one situation may not be in the other.

Start with the Questions

1. Scope - Is it an enterprise application for internal users or a consumer application for external use?

2. Social - Do you need to support

   • OAuth2 or
   • OIDC?

3. MFA - Do you need to support

   • MFA?
4. Scope - Do you need to share the identity across multiple applications?
5. Volume - Do you have an estimate for how many users you need to support?
6. Complexity - do you need custom logic to run as part of your authentication process?

Without the answers to these questions, it will be difficult to choose the right option. With the answers to these questions, you can use the flow charts below to help you choose the right solution.

Your situation is unique, and every application's requirements are different. These flow charts are intended to point you towards what you should consider for your solution.

External Applications

External applications are B2B or B2C applications that are intended for consumption outside of your organization.

Example Template to Customer:

Internal Applications

For internal applications, the below flow chart is intended to assist your decision by guiding you to which option or options to consider for your application. It is possible (and in some cases necessary) to use combinations of these.

Example Template to Customer:

Note #1: All of the following options assume you are building an ASP.NET Core application, although the commercial options listed here provide libraries for most development languages, frameworks, and platforms.

Note #2: The information here is relevant as provided, but consider other factors that may impact your decision too. For example, cost may be a factor and saving money may be more important than the added benefits of higher-cost options. Additionally, your situation may not fit neatly into one of the scenarios we have listed and may span multiple scenarios, in which case you may need to pick the option which caters to the broadest set of requirements (avoid 'mix and match').

ASP.NET Core Identity (simple and free)

ASP.NET Core has some built-in identity functionality that allows you to create users and roles, and manage the security of your web applications. It is extremely capable and can be used to support a broad number of scenarios. However, it is intended for use in simple web applications, and while it can be extended to support other clients, you will need to build and wire up a lot of the UI for these scenarios yourself. Your identity store will be limited to this one application, so your users will not be able to share this identity across multiple applications.

• Free
• Easy to set up and use
• Supports OAuth2/OIDC providers

• It is recommended by Microsoft that for advanced requirements you don't use this on its own - so need to add one of the below
• Does not scale well across multiple applications - so need to add one of the below
• For anything other than an ASP.NET Core Web app (e.g. Angular, React, or mobile), you have to build all UI yourself, such as: sign up, log, password reset, etc.

Use this option if...

• You need to add identity to a simple ASP.NETapplication

Identity Server (full control)

Identity Server is an open-source solution that is built on top of ASP.NET Core Identity. It has extensive support for a number of authentication and authorization scenarios and supports multiple identity providers (OAuth2/OIDC) out of the box. Identity Server extends ASP.NET Core Identity to natively support multiple client types and can be used as a single identity across multiple applications.

Identity Server is a powerful authentication solution and its core strengths are its ability to inject complex, custom logic into your authentication flow and integrate with legacy systems. If you have either of these requirements, it's likely IdenityServer will form an essential part of your solution.

• Inexpensive
• Allows you to define custom authentication logic
• Supports multiple applications/identity consumers
• Supports multiple clients and client types
• Supports OAuth/OIDC

• Steep learning curve
• Requires additional setup
• Requires additional skillset
• Requires additional management

Use this option if...

• You need to inject custom logic into your authentication flow, or:
• You expect to support multiple clients (e.g. web, mobile, etc), and/or:
• You expect to support multiple applications

Active Directory (for Internal Enterprise Applications)

Active Directory has been the de facto enterprise identity store for most of the world for decades. Many organizations already have AD as it provides a lot of additional capability and is integrated with most of their existing enterprise applications. AD supports multiple authentication protocols, including:

• LDAP/LDAPS: simple to use but old tech, requires multiple queries to check permissions, roles not natively supported, and need to be managed by groups.
• Kerberos: Excellent experience for users as it provides a silent and transparent login. But can only be used for on-premises, domain-joined computers.
• ADFS/SAML: Modern application authentication against AD is done via ADFS with SAML. This is often extended through third-party tools such as Okta to support applications that use JWT and claims.
• Proprietary Microsoft: Basic, NTLM, etc.

• Already in place in most enterprise organizations
• Users do not require an additional identity
• Can make the application compliant with the organization's existing security policies

• Not suited to external use
• Can require a lot of setups to work well with company RBAC (e.g. AD groups for authorization)
• Not natively supported off-premises
• No MFA included

Use this option if...

• Your application, domain controllers, and clients are all on the same network, and:
• You already have AD in place and have a security policy that states that all your users must authenticate against your centralized corporate identity, and/or:
• You want to enable pass-through/silent authentication for your users

Azure AD (for Internal Enterprise Applications)

Azure AD is Microsoft's cloud-based version of its traditional on-premises enterprise identity store - Active Directory. Azure AD is different in that it is fundamentally identity only (it doesn't provide endpoint and user management features such as Group Policy) and as such provides strong identity features not natively supported by AD, such as MFA and self-service password recovery. Being cloud-based, it can authenticate users anywhere in the world (rather than just on-premises on corporate computers).

• Many organizations already have AAD
• Extends existing enterprise identity to the cloud (i.e. is supported off-premises)
• Can be used to ensure compliance with existing company security policies
• MFA support included

• Not suited for external or consumer-facing uses

Use this option if...

• You want to support internal/enterprise users, and:
• You already have Azure AD set up, and/or:
• Your users require access from off-site, and/or:
• You need to enforce MFA

Azure B2C (simple Auth as a Service)

AAD B2C sits on top of Azure AD and includes all the benefits it provides, as well as enabling consumer-friendly features. These include integration with OAuth2/OIDC provider and more flexible/customizable login flows. B2C is well-tailored to support authentication, and while it can be extended to support additional capabilities, this requires custom development.

• Inexpensive and generous free tier
• Native support for multiple OAuth2/OIDC providers
• MFA support included
• Relatively straightforward to setup
• Ongoing security maintained by Microsoft

• Very limited flexibility
• Can support roles and other extended functionality, but requires significant development

Use this option if...

• You want to support MFA, and/or:
• Your users are external/consumers, and:
• You anticipate a high volume of users, and/or:
• You only require basic authentication and limited or no authorization

Auth0 (sophisticated Auth as a Service)

Auth0 is a commercial identity product aimed at developers. It is cloud-hosted and offers out-of-the-box functionality for user signup and login, self-service password recovery, OAuth2/OIDC integration, and other consumer and user-friendly features. MFA is supported out of the box, and significant sophisticated functionality is available on the paid tiers.

• Good free tier
• Very easy to set up and use
• MFA support included
• Supports multiple OAuth2/OIDC providers
• Significant extensibility

• Free tier is more limited in volume than competition (B2C)
• Free tier only includes the basic functionality (same as B2C)
• Free tier only supports 2 social identity providers

Use this option if...

• You want to enforce MFA, and/or:
• Your users are external/consumers, and/or:
• You require authorization or complex authentication

Okta (for Commercial Enterprise Applications $)

Okta is a commercial identity product aimed at enterprises. Many enterprise-centric software products, for example, Salesforce, have Okta connectors. Okta is intended to bridge the gap between enterprise authentication (such as AD) and modern software and SaaS products.

• Integrates with anything
• Very well supported in the enterprise
• Can simplify integration with AD

• Expensive
• No free tier
• Not suited to consumer-facing scenarios

Use this option if...

• Your application is for internal/enterprise users, and:
• You already have Okta in place, and/or:
• Your application is a product that you intend to commercialize (Okta is prevalent in the enterprise and having an Okta connector is a good selling point)

Roll your own - a solution looking for a problem :-)

It is entirely possible to create a users table and a roles table in your database and create and manage users yourself.

• Developers feel like they're ninjas for a little while
• Can be a quick and dirty solution to the absolute most basic situation

• You have to reinvent the wheel
• Identity
• Roles
• Email verification
• Login/Signup/Password reset
• Claims management
• Significant risk
• High maintenance overhead
• Masses of technical debt

Use this option if...

• You want a side project to learn more about how you might roll your own, but of course, you know never intend to put it into production :-)

Do you know who is entering your premises, when, and how? Keys or key-cards can be expensive, they can be lost, and people can loan them to one another without any restriction.

There are all kinds of ways to monitor access to your building and more secure areas. While fingerprint scanners are a good way of monitoring and restricting access, they are difficult to use in practice. Not everyone has great fingerprints, and access can be sketchy and frustrating when it doesn't work.

The best way to do control your buildings' access is to use an automated NFC (an acronym for Near Field Communication) Access System like Unifi by Ubiquiti.

• You only need your phone, so there are no keys to lose or replace
• It is easy to add or remove access for staff & visitors
• You can see who is coming and going and when
• It can connect to your security cameras for additional security

To see more about how the system works, watch this cool 4min video from Ubiquiti UniFi Access:

As developers when we think security we commonly become fixated with issues in the code, out of date software versions or incorrectly configured firewalls. However, we miss one glaring vulnerability which there is no patch for... our users.

Social engineering is a technique which mixes art and science to exploit common human behaviours to compromise information systems. The following is a classic example of social engineering performed over the phone.

There are numerous examples of social engineering ranging from phone calls, attackers posing as friends on social media, all the way to sophisticated attempts at phishing users with near-perfect clones of popular websites.

The only solution to social engineering is to train properly and prepare users about the dangers presented by and common techniques used by malicious individuals. For useful information on the topic reference the document ‘Avoiding Social Engineering and Phishing Attacks’ by the United States Computer Emergency Readiness Team or the Pluralsight course Ethical Hacking: Social Engineering by Troy Hunt.

With the above in mind, it is important to review regularly the information availed via search engines and standard operating procedures. Furthermore, it can be useful to test the readiness and alertness of staff by performing mock social engineering attacks.

Take the following situation as an example: the CEO is out of town and decides to use an employee’s laptop left in the office on the weekend, the employee in question is messaged via Skype for their domain password. If the employee is aware of the risks, this poses the company then they would not send the requested credentials and follow proper procedure around reporting a suspected incident.

The following checklist is a good example of areas to focus on:

• Run penetration tests with SSLLabs.com to check how exposed your servers are
• Look for passwords in .config and code (SSW Code Auditor can help)
• Authentication process of identifying who the user is
• Authorization what the user can do within the application
• Licensing to control the usage of the software
• Validation of all inputs in the system (cross site scripting (XSS) and SQL injection)
• No in memory generation of SQL statements (and are they using a good ORM)
• Encryption of passwords and any sensitive data
• Software Licensing protection mechanisms (and a recommendation to a subscription model)
• Methodologies and best practices to reduce your exposure to hostile attacks
• Logging who is doing what and when (audit trails)

There is a more comprehensive list here on GitHub: A practical security guide for web developers.

Did you know that you can stop your users from logging into any of your Azure or Office365 resources based on the location they are in? What about the types of devices that they can connect from or only allowing connections that use MFA? These things are all possible to restrict.

This seriously limits the attack surface and also helps to stop compromised devices and accounts from being used.

Configure locations

First you need to add any locations that you require for your office.

1. Go to https://endpoint.microsoft.com | Endpoint security | Conditional Access | Named locations

2. Click "+ Countries location and add required countries

   

3. Add as many as you require for your users to access

   

Configure policies

Now configure some policies to implement these rules

1. Go to Go to https://endpoint.microsoft.com | Endpoint security | Conditional Access | Policies

2. Select New policy | Create new policy

   

3. Give it a name then select Cloud apps or actions | Select All cloud apps

   

4. Select Conditions | Locations Then set configure to yes and Include to "Any location"

   

5. On Exclude choose Selected locations and then exclude your workers countries (i.e. Australia)

   Note: This must be done this way as the user must not meet a block access rule ever if they are to login.

6. Now select block access for this rule

   

Create a grant rule

7. Similarly create a rule that applies to all cloud apps as above

8. This will be exactly the same as the above rule except that you should not have conditions and should Grant access with MFA

   

9. You will notice that each of these rules have a 'Report only' mode or enforce. You should leave it on report mode and monitor the audit logs.

   Check for any failures and only apply the rules to a small subset of your users before changing them to 'On'. This is very important as you can stop everyone including yourself from logging in.

   

Do you control your Organization's devices? Intune is a feature which focuses on mobile device management (MDM) and mobile application management (MAM). You control how your organization’s devices are used, including mobile phones, tablets, and laptops. You can also configure specific policies to control applications. 

Intune is a part of Microsoft's Enterprise Mobility + Security (EMS) suite. It integrates with Azure Active Directory to control who has access and what they can access.

With Intune, you can:

• Choose to be 100% cloud with Intune, or be co-managed with Configuration Manager and Intune.
• Set rules and configure settings on personal and organization-owned devices to access data and networks.
• Deploy and authenticate apps on devices -- on-premises and mobile.
• Protect your company information by controlling the way users access and share information.
• Be sure devices and apps are compliant with your security requirements.

Managing Devices

When Intune is connected to Azure AD it's automatic enrollment lets users enroll their Windows devices in Intune. To enroll, users add their work account to their personally owned devices or join corporate-owned devices to Azure Active Directory.

• SysAdmins can monitor all the windows devices from Microsoft Endpoint Manager admin center https://endpoint.microsoft.com/?ref=AdminCenter#home

• We can get reports on device compliance at any time.

When using IdentityServer 5 (aka Duende IdentityServer), you don't need to use UseDeveloperSigningCredentials() anymore as it is now enabled by default.

services.AddIdentityServer()
    .AddInMemoryClients(new List<Client>())
    .AddInMemoryIdentityResources(new List<IdentityResource>())
    .AddInMemoryApiResources(new List<ApiResource>())
    .AddInMemoryApiScopes(new List<ApiScope>())
    .AddTestUsers(new List<TestUser>())
    .AddDeveloperSigningCredential();

When using version 5, instead of using IdentityServer4.AccessTokenValidation(), you should use the out of the box AddAuthentication(("Bearer").AddJwtBearer("Bearer") from .NET 5

services.AddAuthentication("Bearer")
    .AddIdentityServerAuthentication("Bearer", options =>
    {
        options.ApiName = "api1";
        options.Authority = "https://localhost:5000";
    });

services.AddAuthentication("Bearer") 
  .AddJwtBearer("Bearer", options =>
    {
      options.Audience = "api1";
      options.Authority = "https://localhost:5000";
    });

For better server security (especially regarding public facing servers), certain security protocols and ciphers should be disabled.

Using a tool called "IIS Crypto 3.2" by Nartac, these protocols can be easily disabled instead of having to manually edit the Registry Keys.

1. Download IIS Crypto 3.2 (https://www.nartac.com/Products/IISCrypto/Download)
2. Run this on the server you wish to lock down
3. Select the best practices button

4. Ensure that TLS 1.0 and TLS 1.1 is also disabled | hit apply
5. The server will need to be rebooted before the settings take effect

The best passwords in the world are the ones you can never possibly remember. Computer generated passwords, with a length of at least 16 characters, offer the most protection. A strong password look something like this:

This is obviously not something you can realistically type in every time you need to use it. Fortunately, the same tools that generate these for us also manage them, storing them securely and automatically entering them into websites and apps for us.

With a password manager, you don't have to remember that strong, unique password for every website. The password manager stores them for you and even helps you generate new, random ones. 

It does not matter which one. There are many great tools out there:

Figure: Why you should use a password manager

It does not matter which one. There are many great tools out there for example:

• Keeper - Enterprise level password manager. Different groups of users can be given access to different passwords according to Business priorities.
• KeePass - keeps all passwords in one database locked by a master key, which should be accessible only by the few people you trust.
• 1Password - syncs passwords and personal data across all your devices. It's not quite as slick or capable as many competitors, but it's still an easy-to-use utility
• Lastpass - matches the capabilities of other top paid password managers and is easy to use. Platform syncing limitations for the free version make it significantly less useful than it was
• BitWarden - Take control of your online password security and manage private data safely from any location or device
• Dashlane - put passwords in their place, we’ll take care of them for you.

---

Some password managers provide a security score for a password - fix it if it’s a low number.

For example, in LastPass you can disable automatic device provisioning and you can manually approve them.This way, a new device can’t get to your passwords even if your username, password and MFA got compromised at the same time. (in case a hacker manages to get into your phone and gets your password to LastPass).

When using service accounts, you should have a specific AD account for each major service.

If an attacker gets into a computer on your network, they can dump hashed credentials of any user that has logged on to that computer from lsass.exe. This is easy to do if you know where to go - thankfully, it is also fairly easy to block!

You can read more about credential dumping here.

Credential Guard was introduced in Windows 10/Server 2016. It runs lsass.exe in an isolated virtualized environment without any device drivers, so that the memory cannot be dumped. Depending on your environment, there are a few ways you can implement Credential Guard.

Group Policy

In a Domain environment, you can roll out Credential Guard with a GPO.

1. Go to Computer Configuration | Administrative Templates | System | Device Guard | Turn On Virtualization Based Security
2. Enable the policy, and set Credential Guard to Enabled with UEFI lock (recommended), or Enabled without lock.

Note: Enabled with UEFI lock means that Credential Guard needs to be disabled in the GPO and on the device to be turned off. Enabled without lock allows Credential Guard to be disabled just with the GPO.

Microsoft Endpoint Manager / Intune

If you use Microsoft Endpoint Manager, you can roll out Credential Guard with an Attack Surface Reduction policy.

1. Go to Microsoft Endpoint Manager | Endpoint Security | Attack surface reduction
2. Create a new policy, or edit an existing one
3. Set Block credential stealing from the Windows local security authority subsystem to Block

More information & other options

For more information or for instructions to implement Credential Guard on a single computer, see Microsoft's documentation on Credential Guard.