JSON Web Token

A JSON Web Token (JWT) is commonly used to package information that grants users with claims to a system. This includes user information and permissions to a resource. The token is often exchange between the server and client view header information. 

 JSON Web Token Format:

• A JWT token consists of three main segments
• Header
• Payload with claims
• Signature
• These three segments are encoded using Base64, then concatenated with periods as separators.
• The header segment provides information on the token type and algorithm
• The payload segment contains an expiration date and the claims associated to the user
• The claims provide information about the user and permissions
• The signature is used to verify the token
• The token is NOT encrypted so anyone with it can read all the properties
• The token is signed by the server so if any of the values are changed, the server will reject it

Decoding a Token:

The image below shows a token with the base64 string on the left, and the the three decoded segments on the right.

What is a Claim?

• Claims are statements about a subject
• User information like name, email, address
• Organization departments, groups
• Roles or permissions to areas of a system
• Contain claims groups for an application to enable button, menus, routes
• Claims are issued by a provider (Security Token Service - STS)
• Packaged in a security token
• Applications use this token and parse the claims

• Claims are mapped to areas of the application to enable the permissions

Authorization Header

The token is exchanged between the server and client as an authorization header. The server sends the base64 string. The client needs to process this information, and when the client application needs to send a request to the server, it must add the Authorization Bearer header as shown below. This is what enables the access to the application.

This is just an overview of what a security token is and its purpose. There are other areas to learn about how to decode and apply those claims to secure the different areas of an application.

Thanks for reading.

Originally published by ozkary.com

Could not load assembly or one of its dependencies

We running a .NET application that uses an unmanaged dynamic-link library (the old famous DLL), we may encountered the following error:

Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format.

The error indicates that the program is not able to load the assembly, but when we look at our project references, we can see the assembly exists.  If we take a look at the message carefully, we can also see that the error tells us that perhaps it is not able load a dependency. But what does this really mean? To understand this, let’s first do a refresh on .NET interoperability

Interoperating with Unmanaged Code

The .NET framework provides interoperation with native C and C++ dynamic-link libraries (DLL) for common Windows API and COM components. These DLLs do not run under the .NET runtime, so this is the reason why they are called unmanaged code. Many products are still written using the native Windows API not the .NET framework. When we try to use these DLL on a .NET application, we need to first import the API using the following directives.

using System.Runtime.InteropServices;  // Use DllImport to import the Win32 MessageBox function.  [DllImport("user32.dll", CharSet = CharSet.Unicode)]  private static extern int MessageBox(IntPtr hWnd,                                             string text,                                             string caption,                                             uint type);

As an example, this import directive allows us to call a Windows API message box function. Off course, when using the .NET framework, we use the framework API MessageBox.Show instead of importing the native API. Use the following gist for a running example:

How does that help on resolving our missing dependency?

It is important to know how interops work with .NET because when we do a DLLImport on an DLL, we are only importing the external library methods, but we do not know if there are downstream dependencies associated to that DLL. To be able to discover our dependencies, we can use the binary file dumper (dumpbin.exe) utility by running the following command:

dumpbin.exe /dependent  myfile.dll

Note: This utility is part of the Visual Studio installation, and it can only run under the Visual Studio command prompt not the system command prompt.

After running this command, we should be able to see a list of DLL dependencies.  These DLLs should be in our system path or the local directory path. The missing unmanaged DLL are usually related to the C++ run time libraries that are installed on the system when we install Visual Studio or SDK packages.. By default, these DLLs are deployed in the system32 folder. We can search for the files listed on the output to make sure they exist. If they don’t, we have found a missing dependency, and we need to install the Visual C++ redistributable package that contains the missing DLL.

Background on Visual C++ Redistributable:

These DLLs are usually deployed by the Visual C++ redistributable packages within Visual Studio. They are part of the Windows system components for reusability, performance and memory management purposes. A big problem with these packages is that some software may have been built with an older version of Visual C++, and it may not exist on the current system. This causes the dependency problem.

To address this problem, we need to search for the missing DLL on the Microsoft web site. This should enable us to download and install the correct package. For example, the package for the Visual C++ 2005 redistributable package can be found at this location:

https://www.microsoft.com/en-us/download/details.aspx?id=5638 

Conclusion;

When we start a new project that requires the use of some unmanaged DLL, we need to inspect those libraries using the dumpbin utility and make sure we have those dependencies installed on the development environment. When we deploy these solutions, we need to also remember to package those dependencies within our solution. Otherwise, the application will crash with the Unable to load assembly error.

Originally published by ozkary.com