In response to my previous post: http://deepstacker.com/2020/03/14/break-on-redirect-in-chrome/

I found the underlying issue to be that of Keycloak not enforcing secure cookies. The Keycloak team fixed this in end of January, but the Keycloak version we were using was from December.

This specific bug was the issue:

https://issues.redhat.com/browse/KEYCLOAK-12125?\_sscc=t

I recently acquired an Android tablet intended to be used for work related purposes. The tablet is connected to the Internet, but not the company wide Intranet, making it a bit hard to synchronize documents, etc.

A Company VPN is provided, running ontop Windows 2012. This VPN allowing Intranet access when connected. Only two protocols are supported by the setup: IKEv2 PEAP and SSTP.

Internet Key Exchange version 2.0 (IKEv2) is a protocol used to setup a secure connection between two entities using the Internet Protocol Security (IPSec) protocol suite. IPSec is on the Network layer, alongside IPv4 and IPv6.

Secure Socket Tunneling Protocol (SSTP) is also a protocol used to setup a secure connection between two entities. This protocol is an application level protocol, building ontop of SSL/TLS. Since the protocol builds on-top of TCP, it is more prone to performance problems due to the throttling nature of TCP, which is not the case with IPSec since the tunnel is maintained using Network level datagrams. SSTP is however a very ‘friendly’ protocol in the sense that it can punch through nearly all firewalls, due to it using a single TCP port: 443 which also the case for normal HTTPS.

While IKEv2 is natively supported by Android (at least on my Galaxy tablet), SSTP is not. Getting IKEv2 to work against the company VPN server has however shown to be near to impossible due to certificate issues with the current setup. What I can tell, the setup at the company uses self-signed certificates that do not 100% comply with IKEv2.

I tried SwanVPN, an app which implements IKEv2. Here I actually got through some of the certificate issues, by fiddling with the connection settings and adding the self signed certificate and self signed root certificate to my trusted certificates on Android. But, VPN could not be established due an error code of NO IDENTITY was thrown back in my face - this I never solved. The error is apparently related to a missing attribute in the certificate: Subject Alternative Names which I am to this day still a bit puzzled about…

Then I looked into using SSTP, which is also supported by our company VPN server. However, SSTP is not natively supported by Android nor by SwanVPN. Googling around, I found VPN Client Pro: https://play.google.com/store/apps/details?id=it.colucciweb.vpnclientpro

After installing this on my Android tablet, the configuration of the VPN was straight forward and more or less equivalent to setting up the VPN on Windows 10.

Best of all, this worked like a charm!!!

I am using JWT access tokens for my latest ASP.NET Core project. Authentication is added in ConfigureServices:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
{
 options.TokenValidationParameters = new TokenValidationParameters()
 {
  ValidateIssuer = true,
  ValidateAudience = true,
  ValidateLifetime = true,
  ValidateIssuerSigningKey = true,
  ValidIssuer = Configuration\["Jwt:Issuer"\],
  ValidAudience = Configuration\["Jwt:Issuer"\],
  IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration\["Jwt:Key"\]))
 };
});

This works well for my SPA application, where I store the access token in localStorage (which is bad).  Moving the JWT access token to a cookie is a better approach, however I want the ability to use JWT Bearer for my APIs. Configuration of Dual authentication where:

1. JWT token can be passed as part of Authorization header
2. And JWT token can be passed as a token.

has proven cumbersome to implement.

A simple approach is to 1. add an access token cookie when forming the token and to 2. fake the Authorization header on the server if an access token is received as a cookie.

In the TokenController, the Cookie is either set or deleted depending on the success of the authorization:

[HttpPost]
public IActionResult Post(\[FromBody\]UserBody user)
{
 IActionResult response = Unauthorized();
 if (this.Authenticate(user))
 {
  var token = this.BuildToken(user);
  response = Ok(new { token = token });
  Response.Cookies.Append("access\_token", token);
 }
 else
 {
  Response.Cookies.Delete("access\_token");
 }

 return response;
}

When a client sends his credentials, the credentials are checked and if successful a token is returned as part of the response. In addition, the token is added to an access_token cookie (which should be httpOnly for security reasons).

To make use of the cookie, we simply forge the Authorization header based upon the value of the cookie. This is done by writing a simple middleware before the app.UseAuthentication() in Startup.Configure.

app.Use(async (context, next)=>
{
 var token = context.Request.Cookies\["access\_token"\];
 if (token != null)
 context.Request.Headers\["Authorization"\] = "Bearer " + token.ToString();
 await next();
});

app.UseAuthentication();

If the cookie exists, it is added to the Authorization header, thus invoking the JWT Bearer authorization mechanism in the pipeline. If the authorization fails in the pipeline, the Cookie is cleared.

Simple as that!

My most recent productivity application, Shortcutty, requires the ability to hook into Windows to capture keydown events. The purpose is to show (or hide) the application whenever the user pressed CTRL+~.

I easily got this to work using the Win32 API + PInvoke in my .NET application. But, on some applications such as my Visual Studio instance, the hook failed by unknown reasons.

After a bit of debugging and digging through online archives on the matter, I quickly realized that the issue was as simple as my application not having administrator rights. The latter is required if I want my application to interact with other applications having higher privileges.

Visual Studio, as it happens, was running with admin-rights - thus my application was unable to hook into it, obviously for security reasons. Generally: a non-administrator process cannot interact with a process having administrator rights. You cannot even drag and drop between applications.

I recently installed MariaDB, a MySQL fork, on a Linux VM in the cloud for testing and development purposes. I really struggled with getting proper access from my dev machine to the installation in the cloud.

Simply put, I just wanted a totally open SQL database for deving and testing, nothing production wise was needed.

MariaDB is by standard pretty secure: a good thing, and does not allow remote access: also a good thing.

Firstly, one has to edit the proper .cnf file under /etc/mysql/* and set the bind-address from 127.0.0.1 to 0.0.0.0. MariaDB by default listens only on the loopback interface, thus making it impossible to reach it from outside either LAN or WAN.

Next up, one needs to restart the service: service mysql restart which will apply the changed bind-address.

Now it is possible to connect from outside, TCP/IP wise, however, the MariaDB user (such as root) needs to be granted access from outside to be able to actually make a logical connection to the DBMS.

This can be done by issuing the following SQL query (in this case, for root with password xyzw):

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'xyzw' WITH GRANT OPTION;

Which will grant root access level from anywhere.

To fire off this SQL, I suggest to simply login to the box using SSH and connect to the mysql CLI using:

sudo mysql -u root

and then fire off the query.