How to auto start and keep an ASP.NET core web application running on IIS

I have an ASP.NET core web application which hosts a background task via the IHosedService interface. I wrote about it in this post, if you want more info. The task needs to run continuously to poll for messages on an azure queue storage every 5 seconds. I have learned the default settings on IIS do not start the application until it receives the first request. Additionally, if the application has not received a request after a predefined period of time, IIS kills the application.

I could have hosted the application as a Windows service or converted the application into a console application and use the Windows scheduler to have it run continuously. However, I find hosting on a real IIS server convenient and beneficial since we already have other applications running on IIS and we can access the application via HTTP.

In this post, I share how I make the application to auto start and always run on IIS.

If you have an ASP.NET or an ASP.NET core which hosts a background job that needs to always run, want to preload the application for performance instead of waiting for the initial request to hit the app, or just get some tips on IIS, then read on.

Continue reading

Azure AD B2B vs Azure AD B2C

In this post, I discuss the features of Azure Active Directory  B2B (AAD B2B) and Azure Active Directory B2C  (AAD B2C), the differences between them and when to use one vs the other.

Continue reading

Encryption in Java with JCA and Bouncy Castle API.

In this post, I cover the basics, what I have learned about encryption while building a module to protect Personal Identifiable Information (PII) data using the Java Cryptography API (JCA) and Bouncy Castle API.

You may find this post helpful if:

• You are new to encryption or not sure how to use the JCA/Bouncy Castle to do encryption in Java.
• You face some issues with key length using the JCA.
• You are not sure which types of encoding to use for encryption.

Secure app settings in ASP.NET Core 2

Update: This post shows how to authenticate to azure key vault using app id/secret. However, this approach is less secure than using managed identity for azure resource and certificate for non-azure resource to grant the resource access to the key vault. For production environment, you should definitely consider using azure managed identity or certificate to authenticate and access azure key vault from your resource. Checkout my other post for more details.

In this blog post, I’ll show you the steps on  how to keep the credentials out of the source code of an ASP.NET Core app using Azure Key Vault.

If you want some convincing examples why leaving secrets in the source code is bad, check out this post. 

I assume you have some familiarity with developing an ASP.NET core 2 app. You also need an Azure subscription to register your application in Azure Active Directory and create an Azure key vault.

Basically the process involves these steps:

1. Register your application in AAD and generate app secret.
2. Set application id/secret using environment variables.
3. Create an Azure Key Vault.
4. Grant your app access to your key vault using access control.
5. Specify URL to your vault in app settings.
6. Load app id and secret from environment variables.
7. Read secrets from Azure Key Vault.

Checkout the sample app for this post from my Git repo.

Continue reading

Cross Site Scripting (XSS)

In a XSS attack, the attacker’s goal is to inject a malicious script into the user’s browser and have the browser execute the script. The vulnerability of web applications to XSS attacks is because of not validating user’s input and/or not encoding/sanitizing data when rendering into a browser. Don’t confuse Cross Site Scripting  with Cross Site Request Forgery (CSRF).

A successful XSS attack could be devastating. Examples of damages include exposing the victim’s sensitive data, displaying  inappropriate/unintended content, involuntarily transferring of money, impersonating the user’s account etc …

XSS attack is listed under the top ten most critical application security risks for 2017.

Several XSS types of attack describe how a malicious script arrives at a user’s browser: stored XSS attacks, reflected XSS attacks, and server vs client XSS attacks.

Continue reading

Why OAuth2 is not for authentication.

If you are like me, you might have thought OAuth 2 is for both authentication and authorization. After all, the main OAuth 2 flows ( Authorization Code, Implicit, User Credentials ) all require a resource owner to authenticate against an authorization server.  In this post, I’ll talk about some of the reasons I’ve learned why OAuth 2 is not for authentication.

Continue reading

OAuth2 – Client Credentials Grant

In this post, I’ll give a high-level overview of the Client Credentials Grant by example.

Client Credentials Grant:

The Client Credentials Grant is for obtaining  an access token based solely on a client’s credentials, without any user’s involvement. Simply put, the Client Credentials Grant is for machine to machine communication.

Continue reading

OAuth2 – Resource Owner Password Credentials Grant

In this post, I’ll discuss the Resource Owner Password Credentials (ROPC) grant and when you should use it.

Overview of the ROPC Grant:

In a ROPC flow, the user gives the credentials directly to the client application, usually by mean of a login form over which the client application has complete control. In this flow, the client application does not redirect the user to an authorization server for authentication. However, the client application submits a request to the authorization server, passing over the user’s credentials to obtain an access token on behalf of the user. If the client is a confidential client or has been provided a secret key, the client also needs to authenticate against the authorization server using its client id and secret when requesting a token.

Continue reading

OAuth 2 – Implicit Grant

This is part of a series post about OAuth2. In this post, I go over the implicit grant type and how it relates and differs to the authorization code grant type.

Let’s look at a high-level only flow of the implicit grant flow via an example in which an application recommends a user movies based on the movies the user’s friends like on Facebook.

1. The user submits a request to the Movie app to get movie recommendations.
2. The app redirects the user to Facebook to authenticate.
3. The user authenticates with Facebook and gives consent for the Movie app to access the user’s Facebook data
4. Facebook sends back an access token to the Movie app via a redirect url.
5. The Movie app uses the access token to request the user’s Facebook data on behalf of the user and provide recommendations to the user.

For comparison, here’s the flow using the authorization code grant.

1. The user submits a request to the Movie app to get movie recommendations.
2. The app redirects the user to Facebook to authenticate.
3. The user authenticates with Facebook and gives consent for the Movie app to access the user’s Facebook data.
4. Facebook sends back an authorization code to the Movie app via a redirect url.
5. The Movie app submits another request to Facebook to request an access token,  passing its client credentials ( client id and secret ) as well as the authorization code obtained from step 4.
6. Facebook validates the client’s credentials and authorization code, then issues an access token and optionally a refresh token back to the Movie app.

As you can see at the surface level, the implicit flow is more or less similar to the authorization code flow except it does not have the step of authenticating the client. As we discuss when to choose the implicit grant type vs the authorization grant type , we’ll explore other differences between the two flows and see they are meant for different types of applications.

Continue reading