SecurityPal

securitypal

JWT stands for , and it is an authorization mechanism, not authentication. So let’s figure out what the difference between those two. JSON Web Token is the mechanism that allows verifying that the user is exactly the one he claims to be. It is a login process where a user provides a username and password, and the system verifies them. So authentication answers the question: who is the user? Authentication is the mechanism that allows verification of which access rights the user has to a certain resource.  It is a process of granting users some roles and a set of permissions a particular role has. So, authorization answers that question: what rights does the user have in the system? Authorization It is important to understand that Authentication always comes first and Authorization is second. In other words, you can’t get permission before you verify your identity. But what are the most popular authorization methods? There are two main approaches to handling authorization for the web application. Sessions A traditional approach on the web for authorization users is a cookie-based server-side session. The process starts when a user logs in and a server authenticates him. After that, the server creates a session with a Session ID and stores it somewhere in the server’s memory. The server sends back Session ID to the client and the client stores the Session ID in cookies. For every request, the client sends a Session ID as a part of the request, and the server verifies the Session ID in its memory and the user’s permissions related to this session. Tokens Another popular approach is using tokens for authorization. The process starts similarly when a user enters login, and passwords and a client sends a login request to a server. Instead of creating a session, the server generates a token signed with the secret token. Then, the server sends the token back to the client, and the client has to store it in a local storage. Similar to the session-based approach, the client has to send a token to the server for every request. However, the server does not store any additional information about the user session. The server has to validate that the token has not changed since it was created and signed with the secret key. Session vs Token Session-based authorization approach can be vulnerable to an attack known as Cross-Site Request Forgery (CSRF). It is a kind of attack when the attacker points to a site they are logged into to perform actions they didn’t intend to, like submitting a payment or changing a password. Another thing is that when using a session-based authorization approach creates a stateful session between a client and server. The problem is if a client wants to access different servers in the scope of the same application, those servers have to share a session state. In another case, the client will need to be authorized on each server since the session is going to be different. On the other hand, the token-based authorization approach does not require storing session data on the server side and may simplify authorization between multiple servers. However, tokens can still be stolen by an attacker and it also can be difficult to invalidate tokens. We will see the details and how to handle invalidation further in this article. JWT JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the algorithm) or a public/private key pair using or . HMAC RSA ECDSA JWT structure JSON Web Tokens consist of three parts separated by dots . Header {
  "alg": "HS256",
  "typ": "JWT"
} The header usually consists of two parts: the type of token, and the signing algorithm being used. Payload {
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
} The payload contains the claims, which are statements about the user. The payload is then encoded to form the second part of the JSON Web Token. You can find a description of standard fields that are used as claims . Base64Url here Signature HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret) To create the signature part, you have to take the encoded header, the encoded payload, a secret, and the algorithm specified in the header and sign that. The token typically looks like the following: xxxxx.yyyyy.zzzzz You can navigate to and debug a sample token or your own. Just paste your token into the field and select the of the token signature. jwt.io Encoded Algorithm .NET project Now that we have theoretical knowledge of how JWT works, we can apply it to the real-life project. Let’s assume we have a simple API that represents CRUD operations for the coffee entity. We are going to create an ASP.NET Core API project that represents Coffee API. After that, we will create another ASP.NET Core API project that would represent an Identity API that could generate JWT. In real life, you would probably use or , or for Authentication/Authorization purposes. However, we would create our own Identity API to demonstrate how to generate JWT. When Identity API is done, we can call its controller and generate JWT based on the user’s data. Also, we can protect the Coffee API with an authorization configuration that requires passing JWT with each request. Identity Server Okta Auth0 Coffee API First, we are going to create a simple ASP.NET Core API project that represents Coffee API. Here is the structure of this project: Let’s start with the in the folder. It is a simple entity with an and a properties. Coffee.cs Model Id Name namespace Hackernoon.Coffee.API.Model;

public class Coffee
{
    public int Id { get; set; }
    public string Name { get; set; }
} We need to store our entities while working with the API. So, let’s introduce a simple in-memory storage. It is located in the file in the folder. Storage.cs Data namespace Hackernoon.Coffee.API.Data;

public static class Storage
{
    private static readonly List<Model.Coffee> Data = new();

    public static List<Model.Coffee> GetAll()
    {
        return Data;
    }
    
    public static bool Create(Model.Coffee model)
    {
        if (Data.Any(c => c.Id == model.Id || c.Name == model.Name))
            return false;
        
        Data.Add(new Model.Coffee
        {
            Id = model.Id, 
            Name = model.Name
        });

        return true;
    }
    
    public static bool Delete(int id)
    {
        if (Data.All(c => c.Id != id))
            return false;
        
        Data.Remove(Storage.Data.First(c => c.Id == id));
        return true;
    }
    
    public static bool Update(Model.Coffee model)
    {
        if (Data.All(c => c.Id != model.Id))
            return false;
        
        Data.First(c => c.Id == model.Id).Name = model.Name;
        return true;
    }
} We need a class that would represent requests to the Coffee API. So, let’s create in the folder. CoffeeRequest.cs Contracts namespace Hackernoon.Coffee.API.Contracts;

public class CoffeeRequest
{
    public int Id { get; set; }
    public string Name { get; set; }
} When it is done, we can implement in the folder that represents CRUD operations for the coffee entity. CoffeeController.cs Controller using Hackernoon.Coffee.API.Contracts;
using Hackernoon.Coffee.API.Data;
using Microsoft.AspNetCore.Mvc;

namespace Hackernoon.Coffee.API.Controllers;

[Route("coffee")]
[ApiController]
public class CoffeeController : ControllerBase
{
    [HttpGet]
    public IList<Model.Coffee> GetAll()
    {
        return Storage.GetAll();
    }
    
    [HttpPost]
    public IActionResult Create([FromBody]CoffeeRequest request)
    {
        var model = new Model.Coffee
        {
            Id = request.Id,
            Name = request.Name
        };

        if (!Storage.Create(model))
            return new BadRequestResult();

        return new OkResult();
    }

    [HttpDelete]
    public IActionResult Delete(int id)
    {
        if (!Storage.Delete(id))
            return new BadRequestResult();

        return new OkResult();
    }

    [HttpPut]
    public IActionResult Update([FromBody] CoffeeRequest request)
    {
        var model = new Model.Coffee()
        {
            Id = request.Id,
            Name = request.Name
        };
        
        if (!Storage.Update(model))
            return new BadRequestResult();

        return new OkResult();
    }
} Coffee API is done, and we can run the project and see Swagger UI as follows: Identity API Let’s create another ASP.NET Core API project that represents Identity API. Here is the structure of this project: Let’s start with the in folder, which represents the request for the generation of a new JWT with and properties. TokenGenerationRequest.cs Contracts Email Password namespace Hackernoon.Identity.API.Contracts;

public class TokenGenerationRequest
{
    public string Email { get; set; }
    public string Password { get; set; }
} We need to implement only that represents the logic of generation JWT. But before we do that NuGet package needs to be installed. TokenController.cs Microsoft.AspNetCore.Authentication.JwtBearer using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using System.Text;
using Hackernoon.Identity.API.Contracts;
using Microsoft.AspNetCore.Mvc;
using Microsoft.IdentityModel.Tokens;

namespace Hackernoon.Identity.API.Controllers;

[Route("token")]
public class TokenController : ControllerBase
{
    private const string SecretKey = "VerySecretAndLongKey-NeedMoreSymbolsHere-123";
    private const string Issuer = "IdentityServerIssuer";
    private const string Audience = "IdentityServerClient";
    private static readonly TimeSpan Lifetime = TimeSpan.FromMinutes(20); 
        
    [HttpPost]
    public string Create([FromBody]TokenGenerationRequest request)
    {
        var claims = new List<Claim> {new Claim(ClaimTypes.Email, request.Email) };

        var jwt = new JwtSecurityToken(
            issuer: Issuer,
            audience: Audience,
            claims: claims,
            expires: DateTime.UtcNow.Add(Lifetime),
            signingCredentials: CreateSigningCredentials());
            
        return new JwtSecurityTokenHandler().WriteToken(jwt);
    }

    private static SigningCredentials CreateSigningCredentials()
    {
        return new SigningCredentials(
            new SymmetricSecurityKey(Encoding.UTF8.GetBytes(SecretKey)), 
            SecurityAlgorithms.HmacSha256);
    }
} Note that sensitive const such as , , and have to be put somewhere in the configuration. They are hardcoded just for simplifying this test project. The field is set to 20 minutes, which means that the token will be valid for that time. You also might configure this parameter. SecretKey Issuer Audience Lifetime Now we can run the project and see Swagger UI as follows: Let’s make a call to the endpoint and generate a new JWT. Try the following payload: /token {
  "email": "john.doe@gmail.com",
  "password": "password"
} Identity API will generate the corresponding JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3MiOiJqb2huLmRvZUBnbWFpbC5jb20iLCJJc0dvdXJtZXQiOiJmYWxzZSIsImV4cCI6MTcwNzc4Mzk4MCwiaXNzIjoiSWRlbnRpdHlTZXJ2ZXJJc3N1ZXIiLCJhdWQiOiJJZGVudGl0eVNlcnZlckNsaWVudCJ9.4odXsbWak1C0uK3Ux-n7f58icYQQwlHjM54OjgMCVPM Enabling Authorization in Coffee API Now, when Identity API is ready and provides us with tokens, we can guard Coffee API with authorization. Again NuGet package needs to be installed. Microsoft.AspNetCore.Authentication.JwtBearer We need to register the required services by authentication services. Add the following code to the file right after creating a builder. Program.cs var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "IdentityServerIssuer",
            ValidateAudience = true,
            ValidAudience = "IdentityServerClient",
            ValidateLifetime = true,
            IssuerSigningKey = 
                new SymmetricSecurityKey(
                    Encoding.UTF8.GetBytes("VerySecretAndLongKey-NeedMoreSymbolsHere-123")),
            ValidateIssuerSigningKey = true,
        };
    });

builder.Services.AddAuthorization(); It is important to remember that order in middleware is important. We enable authentication by calling method and specifying as an authentication schema. It is a constant that contains a value. AddAuthentication() JwtBearerDefaults.AuthenticationScheme Bearer namespace Microsoft.AspNetCore.Authentication.JwtBearer
{
  /// <summary>Default values used by bearer authentication.</summary>
  public static class JwtBearerDefaults
  {
    /// <summary>
    /// Default value for AuthenticationScheme property in the JwtBearerAuthenticationOptions
    /// </summary>
    public const string AuthenticationScheme = "Bearer";
  }
} We need to specify that describes which parameters of JWT will be validated during the authorization. We also specify similar to the in Identity API to verify the JWT signature. Check more details about . TokenValidationParameters IssuerSigningKey signingCredentials TokenValidationParameters here The next piece of code adds middleware to the builder that enables authentication and authorization capabilities. It should be added between the and methods. UseHttpsRedirection() MapControllers() app.UseHttpsRedirection();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers(); Now, we can use the attribute over the controller or its actions. By applying this code, now all the actions in are protected with an authorization mechanism, and JWT has to be sent as a part of the request. Authorize CoffeeController [Route("coffee")]
[ApiController]
[Authorize]
public class CoffeeController : ControllerBase
{
  .. If we make a call to any endpoint of the Coffee API, we can debug and see that it is populated and has an with claims we have specified in JWT. It is an important thing in understanding how ASP.NET Core handles Authorization under the hood. HttpContext.User Identity Add Authorization to Swagger UI We did great work to protect Coffee API with the authorization. But if you run the Coffee API project and open Swagger UI, you won’t be able to send JWT as a part of the request. To fix that, we need to update the file with the following code: Program.cs builder.Services.AddSwaggerGen(option =>
{
    option.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        In = ParameterLocation.Header,
        Description = "Please enter a valid token",
        Name = "Authorization",
        Type = SecuritySchemeType.Http,
        BearerFormat = "JWT",
        Scheme = "Bearer"
    });
    option.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type=ReferenceType.SecurityScheme,
                    Id="Bearer"
                }
            },
            new string[]{}
        }
    });
}); After that, we will be able to see the button at the right top corner: Authorize When you click on the button you will be able to enter JWT as follows: Authorize Use Postman for testing You can not limit yourself to using Swagger UI and can perform testing of the API through the Postman tool. Let’s call endpoint of the Identity API first. We need to specify header with the value in the section since we are going to use JSON as a payload. /token Content-Type application/json Headers After that, we can call endpoint and get a new JWT. /token Now, we can copy JWT and use it to call Coffee API. We need to specify header similar to the Identity API if we want to test, create, and update endpoints. header also has to be set with the value . After that, just hit button and see the result. Content-Type Authorization Bearer [your JWT value] Send Role-based authorization As you remember, the payload part of JWT is a set of claims with values that are exactly key-value pairs. Role-based authorization allows you to differentiate access to application resources depending on the role to which the user belongs. If we update the method in the file in Identity API with the code that adds a new claim for the role; we can handle role-based authentication in the Coffee API. is a predefined name of the role claim. Create() TokenController.cs ClaimTypes.Role var claims = new List<Claim>
{
    new Claim(ClaimTypes.Email, request.Email),
    new Claim(ClaimTypes.Role, "Barista")
}; Update the attribute in the file specifying the role name: Authorize CoffeeController.cs [Authorize(Roles = "Barista")] Now, all users who make a call to Coffee API have to have the role claim with the value. Otherwise, they will get status code. Barista 403 Forbidden Claim-based authorization An attribute can easily handle role-based authentication. But what if it is not enough, and we want to differentiate access based on some user properties like age or any other? You have probably already guessed that you can add your claims to JWT and use them to build authorization logic. Role-based authorization itself is a special case of claims-based authorization, just as a role is the same claim object of a predefined type. Authorize Let’s update the method in the file in Identity API with the code that adds a new claim . Create() TokenController.cs IsGourmet var claims = new List<Claim>
{
    new Claim(ClaimTypes.Email, request.Email),
    new Claim("IsGourmet", "true")
}; In the Program.cs file in Coffee API, we need to create a policy that verifies a claim and can be used in the attribute. The following code has to be added right after the method call. Authorize AddAuthentication() builder.Services.AddAuthorization(opts => {
    opts.AddPolicy("OnlyForGourmet", policy => {
        policy.RequireClaim("IsGourmet", "true");
    });
}); Update the attribute in the file specifying the policy name: Authorize CoffeeController.cs [Authorize(Policy = "OnlyForGourmet")] Summary Congratulations! You made a great effort in learning JWT in .NET. Now, you have to have a solid understanding of JWT principles and why it is important to use it to perform authorization in .NET applications. But we just scratched the surface in the area of authentication and authorization in ASP.NET Core applications. I suggest looking into Microsoft documentation regarding the topics we discussed in this article. There are also a lot of built-in capabilities for authorization and role management in the .NET platform. A good addition to this article could be Microsoft about authorization. documentation

Why do you need JWT in your ASP.NET Core project?

কেন আপনার ASP.NET কোর প্রকল্পে JWT দরকার?

Warum benötigen Sie JWT in Ihrem ASP.NET Core-Projekt?

¿Por qué necesita JWT en su proyecto ASP.NET Core?

Pourquoi avez-vous besoin de JWT dans votre projet ASP.NET Core ?

आपको अपने ASP.NET कोर प्रोजेक्ट में JWT की आवश्यकता क्यों है?

ASP.NET Core プロジェクトに JWT が必要なのはなぜですか?

ASP.NET Core 프로젝트에 JWT가 필요한 이유는 무엇입니까?

Por que você precisa do JWT em seu projeto ASP.NET Core?

Зачем вам нужен JWT в вашем проекте ASP.NET Core?

ASP.NET Core projenizde neden JWT'ye ihtiyacınız var?

Tại sao bạn cần JWT trong dự án ASP.NET Core của mình?

为什么 ASP.NET Core 项目中需要 JWT？

Migrating from Pod Security Policies: A Comprehensive Guide

পড নিরাপত্তা নীতি থেকে স্থানান্তর: একটি ব্যাপক নির্দেশিকা (পর্ব 1: PSA-তে রূপান্তর)

Migration von Pod-Sicherheitsrichtlinien: Ein umfassender Leitfaden (Teil 1: Übergang zu PSA)

Migración desde políticas de seguridad de pod: una guía completa (Parte 1: Transición a PSA)

Migration à partir des politiques de sécurité des pods : un guide complet (Partie 1 : Transition vers PSA)

पॉड सुरक्षा नीतियों से माइग्रेट करना: एक व्यापक मार्गदर्शिका (भाग 1: पीएसए में परिवर्तन)

ポッド セキュリティ ポリシーからの移行: 包括的なガイド (パート 1: PSA への移行)

포드 보안 정책에서 마이그레이션: 종합 가이드(1부: PSA로 전환)

Migração de políticas de segurança de pod: um guia abrangente (Parte 1: transição para PSA)

Миграция с политик безопасности Pod: подробное руководство (Часть 1: Переход на PSA)

Pod Güvenlik Politikalarından Geçiş: Kapsamlı Bir Kılavuz (Bölüm 1: PSA'ya Geçiş)

Di chuyển từ Chính sách bảo mật Pod: Hướng dẫn toàn diện (Phần 1: Chuyển sang PSA)

从 Pod 安全策略迁移：综合指南（第 1 部分：过渡到 PSA）

The Confluent add-on for Ockam Orchestrator enables tamper-proof and end-to-end encrypted message streams through Confluent Cloud, with zero-code changes. The drop-in solution enables companies to exceed common security and compliance requirements without the need for costly rearchitecture or development work. Kafka deployments typically combine authentication tokens and Transport Layer Security (TLS) to protect data moving into and out of Kafka topics. While this does secure data in transit over the Internet, it doesn't provide a complete solution to securing data as it travels Kafka. The Kafka broker will be able to temporarily see the plaintext data. through Encrypting communication both into and out of your Kafka broker combined with encryption of data at rest, inside Kafka, won't be sufficient protection from a data breach if the Kafka broker or the infrastructure it is running on is compromised, as the plaintext data and the keys to decrypt the data are available in memory. Ockam solves these problems, while providing additional risk mitigating benefits and data integrity assurances, via the Confluent add-on for Ockam Orchestrator. Trust your data-in-motion Your team has decided that integrating a stream processing platform into your systems is the best way to meet both the scale and agility needs of your business, and Apache Kafka was the obvious choice for the platform to use. You've also decided to take advantage of using an experienced managed platform in Confluent Cloud so that your team can focus on adding value rather than running infrastructure. The development is complete, the team has a working solution where producers can send data to Confluent Cloud, and consumers are able to receive it on the other side. Communication between your producers, consumers, and Confluent Cloud is encrypted and secure using Transport Layer Security (TLS) so you're about to proceed with moving things into production usage. A security and compliance review has surfaced a problem. While trust Confluent Cloud, the increased focus on reducing supply-chain risk means that having data move through their systems unencrypted no longer meets your security requirements. How do you mitigate the risk to your business should some other vendor in your supply chain have a security breach? You need to be able to ensure that: you There is no possibility for a third-party to read the data while it's in transit A third-party can not modify the data while it's in transit Only authenticated and authorized parties can produce data Without solutions to both of these there is a risk that a security breach in your own supply-chain can not only expose your sensitive data, but cause unexpected downstream escalations of their own. Integrate with no code changes Let me take you through a complete working example of how, in just a few minutes, you can configure and integrate an entire end-to-end solution that ensures that your data is always encrypted and tamper-proof while in motion through Kafka and Confluent. Note: The code examples below may change as we continue to improve the developer experience. Please check for the most up to date documentation. https://docs.ockam.io/ Initial setup of Ockam If you’ve previously set up Ockam you can skip this section and move straight to the two examples below. brew install build-trust/ockam/ockam (if you’re not using brew for package management we have in our documentation) installation instructions for other systems Once installed you need to enroll your local identity with Ockam Orchestrator, run the command below and follow the instructions provided: ockam enroll Configure the Confluent add-on We're assuming here that you've already got a working cluster on Confluent Cloud (and the Kafka Command Line Tools that come with the ), so the first step is to configure your Ockam project to use the Confluent add-on by pointing it to your bootstrap server address: latest Kafka distribution ockam project addon configure confluent \
  --bootstrap-server YOUR_CONFLUENT_CLOUD_BOOTSTRAP_SERVER_ADDRESS We'll then need to save our Ockam project configuration so we can use it later to register our producers and consumer, so save the output to a file name : project.json ockam project information default --output json > project.json As the administrator of the Ockam project, you're able to control what other identities are allowed to enroll themselves into your project by issuing unique one-time use enrollment tokens. We'll start by creating one for our consumer:​ ockam project enroll --project-path project.json --attribute role=member > consumer.token ... and then one for the first producer: ockam project enroll --project-path project.json --attribute role=member > producer1.token The last configuration file we need to generate is , which will be where you store the username and password you use to access your cluster on Confluent Cloud: kafka.config cat > kafka.config <<EOF
request.timeout.ms=30000
security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
        username="YOUR_CONFLUENT_CLOUD_USER_NAME" \
        password="YOUR_CONFLUENT_CLOUD_PASSWORD";
EOF Configure consumers to receive encrypted messages On your consumer node you'll start by creating a new identity (you'll need the Ockam Command installed, so repeat the install instructions if you're doing this on a separate host): ockam identity create consumer Copy the and files from the previous section, and then use them to authenticate and enroll this identity into your Ockam project: project.json consumer.token ockam project authenticate \
  --project-path project.json \
  --identity consumer \
  --token $(cat consumer.token) An Ockam node is a way to connect securely connect different services to each other, so we'll create one here that we'll use to communicate through the Confluent Cloud cluster using the identity we just created: ockam node create consumer \
  --project project.json 
  --identity consumer Once that completes we can now expose our Kafka bootstrap server. This is like the remote Kafka bootstrap server and brokers have become virtually adjacent on : localhost:4000 ockam service start kafka-consumer \
  --node consumer \
  --project-route /project/default \
  --bootstrap-server-ip 127.0.0.1 \
  --bootstrap-server-port 4000 \
  --brokers-port-range 4001-4100 Copy the file across, and use it to create a new topic that we'll use for sending messages between the producer and consumer in this demo (in this case we've called the topic ) kafka.config demo-topic kafka-topics.sh \
  --bootstrap-server localhost:4000 \
  --command-config kafka.config \
  --create \
  --topic demo-topic \
  --partitions 3 The final step is to start our consumer script, pointing it to as our bootstrap server: localhost:4000 kafka-console-consumer.sh \
  --topic demo-topic \
  --bootstrap-server localhost:4000 \
  --consumer.config kafka.config The consumer code will push all communication into the Ockam node process that is running on the local host. That local Ockam process will automatically manage the generation of cryptographic keys, establishing a secure channel for communication with any producer nodes, and then subsequently receiving, decrypting, and forwarding on any messages that are received from the broker running on our Confluent Cloud cluster. Send encrypted messages from multiple producers To have messages for our consumer to process, we need to have something producing them. We'll go through a very similar process now but instead create the parts necessary for a producer. We start once again by creating an identity on the producer's host (again, install the Ockam Command on that host if required): ockam identity create producer1 Copy over the and files from the earlier section and use it to authenticate and enroll into our Ockam project: project.json producer1.token ockam project authenticate \
  --project-path project.json \
  --identity producer1  \
  --token $(cat producer1.token) Create a node and link it to both the project and identity we've created: ockam node create producer1 \
  --project project.json \
  --identity producer1 And expose our Kafka bootstrap server on port so we can start sending messages through Confluent Cloud: 5000 ockam service start kafka-producer \
  --node producer1 \
  --project-route /project/default \
  --bootstrap-server-ip 127.0.0.1 \
  --bootstrap-server-port 5000 \
  --brokers-port-range 5001-5100 Make sure to copy the file across, and start your producer: kafka.config kafka-console-producer.sh \
  --topic demo-topic \
  --bootstrap-server localhost:5000 \
  --producer.config kafka.config Your existing producer code will now be running, communicating with the broker via the secure portal we've created that has exposed the Kafka bootstrap server and Kafka brokers on local ports, and sending messages through to the consumer that was setup in the previous step. However, all message payloads will be transparently encrypted as they enter the node on the producer, and not decrypted until they exit the consumer node. At no point in transit can the broker see the plaintext message payload that was initially sent by the producer. To take this example further you could repeat this step for number of producers by generating a new enrollment token for each, and then repeating the steps in this section. N If you look at the encrypted messages inside Confluent Cloud, they will render as unrecognizable characters like in the following screen capture: End-to-end encrypted message streams An example that only takes a few minutes to implement means it can be easy to miss a number of the important improvements to security and integrity that comes from this approach: : each consumer and producer generates its own cryptographic keys, and is issued its own unique credentials. They then use these to establish a mutually trusted secure channel between each other. By removing the dependency on a third-party service to store or distribute keys you're able to reduce your vulnerability surface area and eliminate single points of failure. Unique keys per identity : by pushing control of keys to the edges of the system, where authenticated encryption and decryption occurs, no other parties in the supply-chain are able to modify the data in transit. You can be assured that the data you receive at the consumer is exactly what was sent by your producers. You can also be assured that only authorized producers can write to a topic ensuring that the data in your topic is highly trustworthy. If you have even more stringent requirements you can take control of your credential authority and enforce granular authorization policies. Tamper-proof data transfer : Ockam secure channels regularly rotate authentication keys and session secrets. This approach means that if one of those session secrets was exposed your total data exposure window is limited to the small duration that secret was in use. Rotating authentication keys means that even when the identity keys of a producer are compromised - no historical data is compromised. You can selectively remove the compromised producer and its data. With centralized shared key distribution approaches there is the risk that all current and historical data can’t be trusted after a breach because it may have been tampered with or stolen. Ockam's approach eliminates the risk of compromised historical data and minimizes the risk to future data using automatically rotating keys. Reduced exposure window All these benefits are possible, today, with no code changes and minimal configuration change to existing deployments. Next steps If you haven't already followed the example in this guide, you can for free by following the instructions in our documentation. get started using Ockam If you’d like to talk specifically about this or other potential use cases for Ockam, the team would be more than happy to . chat with you Alternatively you can join us, and an ever growing community of developers who want to build trust by making applications that are secure-by-design, in the or on . Build Trust Discord server Github Also published . here

How to Move End-to-end Encrypted Data Through Kafka

Cómo mover datos cifrados de extremo a extremo a través de Kafka

Comment déplacer des données chiffrées de bout en bout via Kafka

काफ्का के माध्यम से एंड-टू-एंड एन्क्रिप्टेड डेटा को कैसे स्थानांतरित करें

Kafka を介してエンドツーエンドの暗号化されたデータを移動する方法

Como mover dados criptografados de ponta a ponta por meio do Kafka

Cách di chuyển dữ liệu được mã hóa đầu cuối qua Kafka

如何通过 Kafka 移动端到端的加密数据

In my 11 years as a developer, I have seen so many API's that have major security flaws. They either lack proper authentication or authorisation or both. Developers might feel like everything's ok, since those endpoints are usually not public. But it is a huge security loop hole which anyone can easily target. To better understand API security, let's create a demo project for the FBI. There will be an Admin who can enroll FBI Agents and change their clearance levels. FBI Agents with will be able to access public files, and agents with will be able to access pubic and classified files. Clearance Level 1 Clearance Level 2 But before we get started, here's some theory. How Authentication Works Our Agent has successfully cleared all their exams; time to enroll them. In order to do that they will provide their documents and in return will get their badge. In the above scenario, is like logging in – where once verified, the agent will be provided with a token (badge). This process is called . It determines whether agents are who they claim to be. providing documents Authentication We are going to use JSON Web Tokens (JWT) Bearer tokens for authentication. are a type of token that's generated by servers, and which contain details of the claims/roles of a user trying to login. Bearer tokens are mostly structured tokens like JWT. You can if you want to learn more. Bearer tokens read more about JWT here How Authorisation Works Now since the FBI Agent has gotten their badge, they can enter the FBI building. They are also able to access public files, but when trying to access classified files they get a . 401 error This is because FBI Agent is not to access classified files. determines what agents can and cannot access. authorised Authorisation As mentioned above, the JWT Bearer token contains claims/roles. Based on it, our server decides whether to give access to a private resource or not. Access Flow As you can see in the above diagram, on successful login the server returns a Bearer token. The client uses the bearer token in subsequent calls to access a private resource. These are the two main concepts that we are going to implement in our article. Enough with the theory, show me some code! How to Set Up our Project Create a new project by executing the command from your CLI. It will create a project with a sample WeatherForecast API. dotnet new webapi --name FBI Why work on WeatherForecast when we can work on FBI? Go ahead and delete the WeatherForecast.cs file. Add the necessary dependencies by executing these commands: dotnet add package Microsoft.IdentityModel.Tokens --version 6.9.0
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer --version 5.0.4 In the ConfigureServices function in your Startup.cs file, add the below code: var TokenValidationParameters = TokenValidationParameters
{
    ValidIssuer = ,
    ValidAudience = ,
    IssuerSigningKey = SymmetricSecurityKey(Encoding.UTF8.GetBytes( )),
    ClockSkew = TimeSpan.Zero // remove token expire
}; new "https://fbi-demo.com" "https://fbi-demo.com" new "SXkSqsKyNUyvGbnHs7ke2NCq8zQzNLW7mPmHbnZZ" delay of when We are defining the parameters for validating a token. Make sure that the length of the string for generating SymmetricSecurityKey is 32. Next, setup the services to add authentication for API's like this: services ; .AddAuthentication ( =>
    {
        options. = JwtBearerDefaults.AuthenticationScheme;
    }) options DefaultScheme .AddJwtBearer ( =>
    {
        cfg. = TokenValidationParameters;
    }) cfg TokenValidationParameters The AddAuthentication method registers services required by authentication services. It also configures the JWT Bearer Authentication as the default scheme. The AddJwtBearer enables JWT-bearer authentication and setting the TokenValidationParameters defined above. Now let's add some Authorisation claims for our Agent and Admin. services.AddAuthorization(cfg =>
    {
        cfg.AddPolicy( , => policy.RequireClaim( , ));
        cfg.AddPolicy( , => policy.RequireClaim( , ));
        cfg.AddPolicy( , => policy.RequireClaim( , , ));
        cfg.AddPolicy( , => policy.RequireClaim( , ));
    }); "Admin" policy "type" "Admin" "Agent" policy "type" "Agent" "ClearanceLevel1" policy "ClearanceLevel" "1" "2" "ClearanceLevel2" policy "ClearanceLevel" "2" The AddAuthorization method registers services required for authorisation. We are also adding claims for Admin, Agent, ClearanceLevel1 and ClearanceLevel2 by calling AddPolicy. A claim is a name value pair that represents what the subject is. Since clearance level 2 can also access clearance level 1, we have put in ClearanceLevel1. You can read more about claims . "1", "2" here Lastly, in the Configure method, add the below line just above app.UseAuthorization(); app.UseAuthentication() ; The Admin Controller File Rename your file WeatherForecastController.cs to AdminController.cs. Do change the class name and constructor names as well. Finally, remove everything except the constructor. Microsoft.AspNetCore.Mvc; {
    [ ]
    [ ] : { { }
    }
} using namespace FBI.Controllers ApiController Route( ) "[controller]" public class AdminController ControllerBase ( ) public AdminController Let's create a login API for Admin so that they can get a token to perform other tasks. [ ]
[ ] { Claims = List<Claim>
            { Claim( , ),
            }; Key = SymmetricSecurityKey(Encoding.UTF8.GetBytes( )); Token = JwtSecurityToken( , ,
        Claims,
        expires: DateTime.Now.AddDays( ),
        signingCredentials: SigningCredentials(Key, SecurityAlgorithms.HmacSha256)
    ); OkObjectResult( JwtSecurityTokenHandler().WriteToken(Token));
} HttpPost Route( ) "[action]" IActionResult ( ) public Login [FromBody] User User // Authenticate Admin with Database TODO: // If not authenticate return 401 Unauthorized // Else continue with below flow var new new "type" "Admin" var new "SXkSqsKyNUyvGbnHs7ke2NCq8zQzNLW7mPmHbnZZ" var new "https://fbi-demo.com" "https://fbi-demo.com" 30.0 new return new new In the above code, User is a model with properties Username and Password. We are also creating an object of JwtSecurityToken using configurations that we have used in our Startup.cs file. The token is then converted to a string and returned in an OkObjectResult. You can now open Swagger and execute the API to see a bearer token. A bearer token will be returned as you can see below. Keep the token handy since we are going to use it in the next section. You can also visit to analyse your token. https://jwt.io How to Generate the Badge API Generating the badge for an Agent is a sensitive task and should only be authorised by an Admin. We are going to add an Authorize attribute for the GenerateBadge API. [ ]
[ ]
[ ] { CreatedResult( , Agent);
} HttpPost Route( ) "[action]" Authorize(Policy = ) "Admin" IActionResult ( ) public GenerateBadge [FromBody] Agent Agent // Add the agent to the database TODO: return new "Agent/1" Here, Agent is a model with properties Name as string and ClearanceLevel as int. Now when you go back to swagger and try to execute the GenerateBadge API it will give you a 401 Unauthorised response. We are getting this error because we have not passed the bearer token. To be able to add the Authorize header in Swagger, change the services.AddSwaggerGen as below: services.AddSwaggerGen(c =>
{
    c.SwaggerDoc( , new OpenApiInfo { Title = , Version = });
    c.AddSecurityDefinition( , new OpenApiSecurityScheme
    { = ParameterLocation.Header,
        Description = ,
        Name = , = SecuritySchemeType.ApiKey
    });
    c.AddSecurityRequirement(new OpenApiSecurityRequirement {
    { new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference { = ReferenceType.SecurityScheme, Id = }
            },
        new string[] {}
    }
    });
}); "v1" "FBI" "v1" "Bearer" In "Please enter JWT with Bearer into field" "Authorization" Type Type "Bearer" When you refresh Swagger in your browser you will notice an button on the right side above the list of APIs. Authorize Click on the newly added Authorize button in Swagger which will open up a dialog. We need to mention what type of token it is. So first enter in the field then a space and then the token generated from the API from the previous section. Bearer /Admin/Login Click on the header to lock in the token. Now you are all set. When you execute the GenerateBadge API again you will get a token (analogous to badge). Keep this token handy, since we require it in the next section. Also make sure to for now. pass ClearanceLevel as 1 How to Set Up the Agent Controller Create a new file called AgentController.cs with the below content: Microsoft.AspNetCore.Mvc; {
    [ ]
    [ ]
    [ ] : { { }
    }
} using namespace FBI.Controllers ApiController Route( ) "[controller]" Authorize(Policy = ) "Agent" public class AgentController ControllerBase ( ) public AgentController As you can see above, we are authorising the whole controller for Agent's access only. So even Admin won't be able to access the API's we are going to create. How to Access the Record's APIs Let's add the APIs to access both public and classified files. [ ]
[ ]
[ ] { OkObjectResult( );
}

[ ]
[ ]
[ ] { OkObjectResult( );
} HttpGet Route( ) "[action]" Authorize(Policy = ) "ClearanceLevel1" ActionResult<String> ( ) public AccessPublicFiles return new "Public Files Accessed" HttpGet Route( ) "[action]" Authorize(Policy = ) "ClearanceLevel2" ActionResult<String> ( ) public AccessClassifiedFiles return new "Classified Files Accessed" We have added the Authorize attribute's for both API's such that public files can be accessed by ClearanceLevel1 and classified files can be accessed by ClearanceLevel2. If you try to access these API's with the Admin token you will get 403 Forbidden error. So go ahead and click on the button again and click on . Then, get the token from the above step and paste in the field with as a prefix Authorize logout Bearer . Now when you access the API you will see response 200 with the message . But when you try the classified API you get the 403 Forbidden error. /Agent/AccessPublicFiles Public Files Accessed How to Change the Clearance Level Fast forward 3 years and our performance has been mind bogglingly good. Management has now decided to promote them to ClearanceLevel2. Agent's The goes to the and asks them to provide a token/badge with Clearance Level 2. Agent Admin The calls the API to generate their own token first. They then enter it in the dialog. Admin /Admin/Login Authorize The admin then calls the API with value 2 in the ClearanceLevel. This generates a new token/badge which they then hand over to . /Admin/GenerageBadge Agent The enters this token/badge in the dialog and when they now call they are pleased to see the result . Agent Authorize /Agent/AccessClassifiedFiles Classified Files Accessed Conclusion You can find the whole project on GitHub. here API security is extremely important and shouldn't be taken lightly, even if it's for internal use only. Setup Authentication and Authorisation and you are halfway there. There are other other security measures you can take against DDoS attacks, accepting API's from a particular IP or domain only, and so on. How did you like the article? What other security measures do you usually take? Any feedbacks or comments? You can checkout out more tutorials . here Previously published at https://arjavdave.com/2021/03/31/net-5-setup-authentication-and-authorisation/

Authentication And Authorization In .NET 5: How It Works

In the core of many trades are often put in place Codes of Conduct that will allow workers to adhere to guidelines that are mostly associated with the respect of human rights. These codes can be heard intrinsically and do not necessarily have an official contractual value, but in case the parties agree that the non respect of these « rules » has been reached, the one who committed the transgression may get sanctions, for ethical reasons. One of the most striking examples in the field of ethics is the , which allows medicine to ensure the proper practice of its profession. However, there are modern forms of guidelines, such as the Declaration of Geneva, established in 1948, which implies how medical research should respect the principle of consent and the protection of confidential information. Except that today we are in 2018 and the world we know is experiencing differences that radically change the way we communicate our disagreement when a transgression is made. In addition to that, information can leak and the potential of personal data has never reached such vulnerability. Thereby, the updated modern versions of the Hippocratic Oath along the years. The last one is the , and it concerns the Hippocratic Oath World Medical Association Declaration of Taipei Research on Health Databases, Big Data and Biobanks. If we recognize that this kind of declarations can establish a list of statements that requires scientific research to regulate human experimentation in order to maintain an acceptable framework of practice (this includes the consent of the participants in the research concerned), we should recognize that we are now facing another form of human experimentation that needs substantial ethical consideration: the use of our personal data circulating within a virtual network. It would be potentially necessary to think that we would need particular driving instructions that concern this virtual domain, because the question touches the whole world today. It is no longer a secret that the information we deliberately share on social networks such as Facebook become potential data for commercial or even political purposes, as was the case with . Cambridge Analytica In this precise example, it seems clear that their “analysis” concerns the field of research. But if the use of personal data has been carried out in an intrusive and non-consenting manner, then we may be able to compare it with an act that has exceeded the ethical rules of the proper use of data that belongs to private property. It is indeed possible to see a violation of the rights of consent on the use of personal data, as we may follow with the Declaration of Helsinki adopted in 1964 where it is stated that « ». it is the duty of physicians who are involved in medical research to protect the life, health, dignity, integrity, right to self-determination , privacy, and confidentiality of personal information of research subjects . The purpose of the several declarations regulated by the World Medical Association was to enable researchers in the field of medicine to moderate the possibilities of abuse concerning the potential activities of experimentation on the human being. It was therefore a moral means for the time to respect human dignity as a priority over the techno-scientific possibilities that continue to grow today. The current problem we face today is however a bit different. The collection of personal data is supposed to be understood as a hidden trade between a free service in exchange of personal data, which can also be called . However, according to a recent investigation, . While this is an extreme situation that goes beyond any moral respect for the consenting use of privacy-related data, there is another aspect of our world that is finally not as obscure and that should be developed honestly, actually, as the consumption of these tools is becoming more and more common: the IoT ( ). If the adoption of such technological equipments are understood to function specifically as data gatherers, ? Economics Privacy Facebook would have liked to collect medical data in order to associate them with profiles registered on the network Internet of Things what could happen if the said tools collecting personal data do not aim medical purposes but contain the greatest potential of private information From this reality, it would seem that we are dealing with a new need: the ability for users to feel the right to own the responsibility to control their personal information given to any device or network that involves the collection of personal data. Let’s take a look at the : Declaration of Taipei « Respecting the dignity, autonomy, privacy and confidentiality of individuals, physicians have specific obligations, both ethical and legal, as stewards protecting information provided by their patients. and biological material. » The rights to autonomy, privacy and confidentiality also entitle individuals to exercise control over the use of their personal data So as to honor the liability that arises from their products, each society that wants to study the personal set of data of their users should consider the same respect for dignity than the medical practitioners. Especially because . The ideal case would require a moral transparency from the companies that collect personal data, in order to allow their users to control the circulation of those information and thus be aware when these data are used by a third party. For example, in Europe, , which allows each individual to be notified when private data are inquired by a third party, such as the police or the medical sector. (see for more information on this type of projects). most of the information collected go beyond what is consensually shared Estonia has already put in place such a system The world of the virtual industry should follow the honest transparency of this system SecurityPledge Let’s try to see the current case as if a collection of data aimed at a scientific or marketing research project had to be realized. Let’s say it involves personal data, shared voluntary or not on the Internet. In order to respect the « », it should be necessary to obtain the consent of the person whose information will be used. There should be no problem with this consent being given, as users would be willing to agree to share their data if they are aware that it could be used to improve their condition, for example. In the case of medical research, only 7% would disagree to share their personal data. rights to autonomy, privacy and confidentiality [that] entitle individuals to exercise control over the use of their personal data Tweet made by @NilsyDesaint Chart presented during the #DigitalDay18 for the European countries join Blockchain Partnership However, what makes the need for consent even more necessary today, goes beyond a medical necessity, as personal data can also be collected via sex toys. Furthermore, a list of criteria that respect our legitimate right of control over our personal information, as stated in the World Medical Association declarations, should become a unavoidable ethical priority in our world today. The certification of these principles are already in practice, for example with the . Open Internet things Certification Mark When we consider the uncertain future regarding the use of personal data circulating on the Internet, the objective is not to cancel their collection, but to put in place a regulation which makes it possible to validate a research only if the participants consciously consented to the use of their data. Just as the ethical minimum of every scientific research should be, one should not be allowed to validate an experiment having used personal data if they have not received the official and informed consent of their participants. Each study that collects personal data beyond the informed consent of the owners of those data should be considered illegal or invalid. Cases where the use of personal data should be re-considered: Facebook’s controversial collection of Data Cambridge Analytica on Brexit Ashley Madison data dump Facebook’s use of advertisements Facebook’s non-consensual social experiment Big Data and politics Artificial intelligence and biased decisions Personal identity Services’ price based on personal data A large amount of personal data is upon our responsibility. The awareness of our common sense should therefore be the priority after all.

Why a declaration on the ethical use of data is necessary?

As the founder of ScaleVoice, I'm leveraging my background in AI and automotive e-commerce to revolutionize sales operations. Our company provides autonomous AI voice sales agents that act as "superhero sidekicks" for automotive sales teams, handling outbound calls, SMS, and chat conversations with human-like proficiency. With a track record of facilitating more than $7 million in monthly car purchases for our clients and processing over one million calls per month, ScaleVoice is at the forefront of AI-powered sales solutions, delivering tangible results and redefining customer engagement in the automotive industry. 1. What is your company in 2–5 words? Ondrej Kuchta: Autonomous AI voice sales agent 2. Why is now the time for your company to exist? OK: VC firm Andreessen Horowitz recently stated, "We believe AI will fundamentally reimagine core systems and sales workflows, leaving no incumbent safe." This paradigm shift presents opportunities for companies like ScaleVoice that specialize in complex, long-term customer journeys. ScaleVoice combines cutting-edge AI expertise with deep automotive sales knowledge. Unlike traditional chatbots that follow strict scripts, our AI agents make decisions based on the conversation context. We focus on delivering tangible results rather than just selling software. Our approach manages end-to-end workflows, from initial customer contact through appointment scheduling and follow-ups. This comprehensive solution sets us apart in the market, where many competitors offer more limited functionality. 3. What do you love about your team, and why are you the ones to solve this problem? OK: I believe we are at the forefront of combining cutting-edge AI expertise with deep industry knowledge. We're not just tech experts - we're domain specialists who understand the unique challenges facing businesses in the automotive space. Our team's blend of skills and experience is what makes us uniquely qualified. We've got seasoned AI researchers and engineers working alongside former automotive executives and sales professionals. This cross-pollination allows us to develop solutions that are technologically sophisticated and grounded in real-world practicality. Equally important, we're passionate problem-solvers driven by results. This outcome-focused mindset permeates everything we do. 4. If you weren’t building your startup, what would you be doing? OK: I'd likely explore other AI applications in business or work on another transformative tech startup. My background spans roles from kernel development to founding my own startups in fitness, retail and home security.Prior to ScaleVoice, I served as the CTO at Driverama, a Germany-based e-commerce platform using data to facilitate used car transactions in Western Europe. Under my leadership, we experienced remarkable growth, expanding from four employees to 250 and increasing revenue from zero to $40 million in less than two years. My success in helping auto dealerships acquire vehicles at Driverama revealed even more opportunities to leverage cutting-edge AI technologies that previously weren't sufficiently advanced or didn't exist. These experiences, combined with the emergence of powerful new AI tools, made the timing perfect for launching ScaleVoice. So while I'm always open to new opportunities, I'm currently laser-focused on ScaleVoice's mission to redefine the future of sales through AI-powered operations. The potential is limitless, and I can't imagine doing anything else. 5. At the moment, how do you measure success? What are your metrics? OK: We have a unique success-based pricing model, which means we only make money when our clients make a sale. Our key metrics include sales volume for our customers, agent success rate, lead response time, and overall call volume which currently exceeds one million per month. At the end of the day, we're not selling software - we're delivering work. 6. In a few sentences, what do you offer to whom? OK: ScaleVoice acts as a "superhero sidekick" for sales teams in automotive and related sectors. Our autonomous AI agents handle outbound calls, SMS, and chat conversations as well as humans. They contact potential car sellers within seconds of their expressed interest, which helps convert more leads into qualified appointments. Most customers don't even realize they're interacting with an AI agent, which means more efficient, consistent conversations and happier customers overall. 7. What’s most exciting about your traction to date? The most exciting aspect of our traction is the consistent, measurable performance of our AI agents in real-world applications. Our work with Aures, the largest Central European dealer of pre-owned cars, has been a particularly significant milestone for us. We're currently facilitating more than $7 million in monthly car purchases for Aures. This impressive figure demonstrates the scalability and effectiveness of our product, even in uncertain market conditions. These kinds of results truly showcase the impact of our technology. Our AI agents aren't just talking the talk - they're delivering tangible business results for our clients. It's exciting to see our solution making such a substantial difference in the automotive sales landscape. 8. Where do you think your growth will be next year? Next year, we expect significant growth as we expand into the US market this fall, targeting states with high concentrations of car dealerships like California, New York, and Texas. We're confident that our proven track record in Europe will translate well to the American market, where businesses are equally hungry for innovative solutions to streamline their customer operations.We also plan to expand into related verticals like car insurance, financing and even the energy sector. These are ambitious moves, but we’ll never shy away from going after challenging verticals as the demand for our technology continues to grow. 9. Tell us about your first paying customer and revenue expectations over the next year. While I can't disclose specific client details, our success with Aures is indicative of our revenue potential. 10. What’s your biggest threat? One of our biggest threats is the rapid pace of AI development and potential competition. We’re staying ahead by continuously enhancing our AI-driven solution to provide even greater value to dealerships and sales teams. We're also developing deeper integrations with management systems and CRMs, enabling more tailored interactions and ability to handle even more complex workflows. For example, our system will soon be able to recognize when a customer's vehicle needs a tire change and facilitate that service on the spot. Beyond single calls, we're developing our AI's ability to manage and convert customers across a series of interactions, creating a cohesive and long-term engagement strategy. Ultimately, our deep industry understanding and laser-focus on tangible outcomes are our biggest advantages. While competitors may try to catch up, we're committed to staying steps ahead through continuous innovation and an unwavering commitment to results. This startup founder interview template is based on HackerNoon Founder & CEO David Smooke’s ten questions for startup founders. Would you like to take a stab at answering some of these questions? The link for the template is HERE. As the founder of ScaleVoice, I'm leveraging my background in AI and automotive e-commerce to revolutionize sales operations. Our company provides autonomous AI voice sales agents that act as "superhero sidekicks" for automotive sales teams, handling outbound calls, SMS, and chat conversations with human-like proficiency. With a track record of facilitating more than $7 million in monthly car purchases for our clients and processing over one million calls per month, ScaleVoice is at the forefront of AI-powered sales solutions, delivering tangible results and redefining customer engagement in the automotive industry. 1. What is your company in 2–5 words? Ondrej Kuchta: Autonomous AI voice sales agent 2. Why is now the time for your company to exist? OK: VC firm Andreessen Horowitz recently stated , "We believe AI will fundamentally reimagine core systems and sales workflows, leaving no incumbent safe." This paradigm shift presents opportunities for companies like ScaleVoice that specialize in complex, long-term customer journeys. Andreessen Horowitz recently stated Andreessen Horowitz recently stated ScaleVoice ScaleVoice ScaleVoice combines cutting-edge AI expertise with deep automotive sales knowledge. Unlike traditional chatbots that follow strict scripts, our AI agents make decisions based on the conversation context. We focus on delivering tangible results rather than just selling software. Our approach manages end-to-end workflows, from initial customer contact through appointment scheduling and follow-ups. This comprehensive solution sets us apart in the market, where many competitors offer more limited functionality. 3. What do you love about your team, and why are you the ones to solve this problem? OK: I believe we are at the forefront of combining cutting-edge AI expertise with deep industry knowledge. We're not just tech experts - we're domain specialists who understand the unique challenges facing businesses in the automotive space. Our team's blend of skills and experience is what makes us uniquely qualified. We've got seasoned AI researchers and engineers working alongside former automotive executives and sales professionals. This cross-pollination allows us to develop solutions that are technologically sophisticated and grounded in real-world practicality. Equally important, we're passionate problem-solvers driven by results. This outcome-focused mindset permeates everything we do. 4. If you weren’t building your startup, what would you be doing? OK: I'd likely explore other AI applications in business or work on another transformative tech startup. My background spans roles from kernel development to founding my own startups in fitness, retail and home security. Prior to ScaleVoice, I served as the CTO at Driverama, a Germany-based e-commerce platform using data to facilitate used car transactions in Western Europe. Under my leadership, we experienced remarkable growth, expanding from four employees to 250 and increasing revenue from zero to $40 million in less than two years. My success in helping auto dealerships acquire vehicles at Driverama revealed even more opportunities to leverage cutting-edge AI technologies that previously weren't sufficiently advanced or didn't exist. These experiences, combined with the emergence of powerful new AI tools, made the timing perfect for launching ScaleVoice. So while I'm always open to new opportunities, I'm currently laser-focused on ScaleVoice's mission to redefine the future of sales through AI-powered operations. The potential is limitless, and I can't imagine doing anything else. 5. At the moment, how do you measure success? What are your metrics? OK: We have a unique success-based pricing model, which means we only make money when our clients make a sale. Our key metrics include sales volume for our customers, agent success rate, lead response time, and overall call volume which currently exceeds one million per month. At the end of the day, we're not selling software - we're delivering work. 6. In a few sentences, what do you offer to whom? OK: ScaleVoice acts as a "superhero sidekick" for sales teams in automotive and related sectors. Our autonomous AI agents handle outbound calls, SMS, and chat conversations as well as humans. They contact potential car sellers within seconds of their expressed interest, which helps convert more leads into qualified appointments. Most customers don't even realize they're interacting with an AI agent, which means more efficient, consistent conversations and happier customers overall. 7. What’s most exciting about your traction to date? The most exciting aspect of our traction is the consistent, measurable performance of our AI agents in real-world applications. Our work with Aures , the largest Central European dealer of pre-owned cars, has been a particularly significant milestone for us. Our work with Aures Our work with Aures We're currently facilitating more than $7 million in monthly car purchases for Aures. This impressive figure demonstrates the scalability and effectiveness of our product, even in uncertain market conditions. These kinds of results truly showcase the impact of our technology. Our AI agents aren't just talking the talk - they're delivering tangible business results for our clients. It's exciting to see our solution making such a substantial difference in the automotive sales landscape. 8. Where do you think your growth will be next year? Next year, we expect significant growth as we expand into the US market this fall, targeting states with high concentrations of car dealerships like California, New York, and Texas. We're confident that our proven track record in Europe will translate well to the American market, where businesses are equally hungry for innovative solutions to streamline their customer operations.We also plan to expand into related verticals like car insurance, financing and even the energy sector. These are ambitious moves, but we’ll never shy away from going after challenging verticals as the demand for our technology continues to grow. 9. Tell us about your first paying customer and revenue expectations over the next year. While I can't disclose specific client details, our success with Aures is indicative of our revenue potential. 10. What’s your biggest threat? One of our biggest threats is the rapid pace of AI development and potential competition. We’re staying ahead by continuously enhancing our AI-driven solution to provide even greater value to dealerships and sales teams. We're also developing deeper integrations with management systems and CRMs, enabling more tailored interactions and ability to handle even more complex workflows. For example, our system will soon be able to recognize when a customer's vehicle needs a tire change and facilitate that service on the spot. Beyond single calls, we're developing our AI's ability to manage and convert customers across a series of interactions, creating a cohesive and long-term engagement strategy. Ultimately, our deep industry understanding and laser-focus on tangible outcomes are our biggest advantages. While competitors may try to catch up, we're committed to staying steps ahead through continuous innovation and an unwavering commitment to results. This startup founder interview template is based on HackerNoon Founder & CEO David Smooke’s ten questions for startup founders. This startup founder interview template is based on HackerNoon Founder & CEO David Smooke ’s ten questions for startup founders . HackerNoon Founder & CEO David Smooke ten questions for startup founders Would you like to take a stab at answering some of these questions? The link for the template is HERE. Would you like to take a stab at answering some of these questions? The link for the template is HERE. The link for the template is HERE.

10 Questions for Every Startup Founder with ScaleVoice Co-founder & CEO, Ondrej Kuchta

Wazuh on Docker: Secure Your Dashboard with Let's Encrypt and Deploy Agent with Kubernetes Daemonset

How to Release a New Version of an Open Source Project Under the Apache Software Foundation

Product and infrastructure engineering teams are not always aligned with the interests of security engineering teams. While product and infrastructure focus on driving business value and delivering practical solutions, security focuses on detection, prevention, and remediation, which can seem less immediately valuable. Like an insurance policy, it's not entirely obvious why it's worth the money or effort when there hasn't been an incident yet. Instead of the traditional cycle of identifying vulnerabilities, applying remediation, and following up through case management, I've found it much more effective to advocate for security solutions that also deliver business value. For example, using OAuth and IAM-based access instead of static keys and encryption instead of more granular access control can significantly simplify infrastructure, reduce complexity, and lessen the operational burden, making them very appealing to both product and platform engineering teams. An Example: Replace Static Keys with IAM-Based OAuth Traditionally, access between systems is implemented via static key-secret pairs. While common, this method often leads to reliability issues due to the complexity of managing key generation, rotation, and application lifecycle. Platform teams must also invest significant effort in monitoring and detecting anomalies to prevent unexpected key-secret compromises, such as accidental exposure via Slack or GitHub. Even when developers report and remediate leaks, the rotation process can be laborious. Worse, developers may consider it a low-risk leak, and the leak can go unreported. According to ISO/IEC 27001:2022, A.9.1 Organizations must implement policies and procedures to control access to information, ensuring it is only accessible to those with a legitimate need Platform teams have two choices: Add more complex access controls and approval processes.
Replace static key-secret pairs with IAM-based OAuth. The first option can be tempting, as it involves simply adding a vendor like ServiceNow without much additional work. However, the second option, while requiring more implementation changes, is more secure and reduces the operational burden on application teams to update secrets, restart pods, and ensure secrets are picked up. In fact, several companies focusing on non-human identity authentication, such as P0 and Clutch, have recently emerged, highlighting the growing trend towards more secure and efficient authentication methods. This example demonstrates how a different approach to security implementation can improve security standards, simplify infrastructure architecture, and enhance overall developer velocity. The Case for Data Encryption Data encryption is another example where, although security teams cannot simply "add a vendor" (we'd like to be that vendor one day), it significantly reduces complexity and implementation efforts across all platforms from both security and architecture design standpoints. The typical data flow involves: Source application publishes data
Data is sent to a transport layer (e.g., Kafka, Kinesis)
Data is stored in a database (MySQL, Postgres), data warehouse (Redshift, Snowflake), or data lake (S3, Databricks) Different solutions have different interpretations and implementations of "access control," leading platform teams to implement their own versions. This often results in fragmented implementations across the company. For security engineers, the more fragmented the implementations are, the more difficult it is to implement standardized governance, control, and monitoring, ultimately making the system less secure. Infrastructure/Vendor Auth and Permission Comparison Platform

IAM-Based Auth

Row/Column Permissions



Databricks

Supports IAM-based permissionsLink

Supports row and column-level securityLink



Snowflake

Does not natively support IAM-based permissionsLink

Supports row and column-level security



MySQL

Does not support IAM-based permissions

Supports row and column-level security through grants and policiesLink



PostgreSQL

Does not support IAM-based permissionsLink

Supports row and column-level security With data encryption, access is configured once with a crypto key and can then be assigned to individual workloads at different stages of the data flow. This significantly reduces the complexities involved in implementing and aligning permission policies across different platforms. Encryption ensures that data is consistently protected across all platforms, simplifying governance and control while enhancing overall security. Let Keyper Up Your Data Encryption Game Keyper by Jarrid empowers engineering teams to embed data encryption in any data handling process to streamline security implementation. Keyper offers a suite of crypto key management APIs designed to simplify key creation, management, deployment, and encryption/decryption. By integrating with cloud KMS services like AWS KMS and GCP KMS, Keyper enables managed crypto key generation, reducing infrastructure maintenance. This allows organizations to configure encryption once and apply it consistently across all stages of the data flow, ensuring robust security while simplifying governance and operational processes. Product and infrastructure engineering teams are not always aligned with the interests of security engineering teams. While product and infrastructure focus on driving business value and delivering practical solutions, security focuses on detection, prevention, and remediation, which can seem less immediately valuable. Like an insurance policy, it's not entirely obvious why it's worth the money or effort when there hasn't been an incident yet. Instead of the traditional cycle of identifying vulnerabilities, applying remediation, and following up through case management, I've found it much more effective to advocate for security solutions that also deliver business value. For example, using OAuth and IAM-based access instead of static keys and encryption instead of more granular access control can significantly simplify infrastructure, reduce complexity, and lessen the operational burden, making them very appealing to both product and platform engineering teams. An Example: Replace Static Keys with IAM-Based OAuth Traditionally, access between systems is implemented via static key-secret pairs. While common, this method often leads to reliability issues due to the complexity of managing key generation, rotation, and application lifecycle. Platform teams must also invest significant effort in monitoring and detecting anomalies to prevent unexpected key-secret compromises, such as accidental exposure via Slack or GitHub. Even when developers report and remediate leaks, the rotation process can be laborious. Worse, developers may consider it a low-risk leak, and the leak can go unreported. According to ISO/IEC 27001:2022, A.9.1 ISO/IEC 27001:2022, A.9.1 Organizations must implement policies and procedures to control access to information, ensuring it is only accessible to those with a legitimate need Organizations must implement policies and procedures to control access to information, ensuring it is only accessible to those with a legitimate need Platform teams have two choices: Add more complex access controls and approval processes. Replace static key-secret pairs with IAM-based OAuth. Add more complex access controls and approval processes. Replace static key-secret pairs with IAM-based OAuth. The first option can be tempting, as it involves simply adding a vendor like ServiceNow without much additional work. However, the second option, while requiring more implementation changes, is more secure and reduces the operational burden on application teams to update secrets, restart pods, and ensure secrets are picked up. In fact, several companies focusing on non-human identity authentication, such as P0 and Clutch , have recently emerged, highlighting the growing trend towards more secure and efficient authentication methods. ServiceNow P0 Clutch This example demonstrates how a different approach to security implementation can improve security standards, simplify infrastructure architecture, and enhance overall developer velocity. The Case for Data Encryption Data encryption is another example where, although security teams cannot simply "add a vendor" (we'd like to be that vendor one day), it significantly reduces complexity and implementation efforts across all platforms from both security and architecture design standpoints. The typical data flow involves: Source application publishes data Data is sent to a transport layer (e.g., Kafka, Kinesis) Data is stored in a database (MySQL, Postgres), data warehouse (Redshift, Snowflake), or data lake (S3, Databricks) Source application publishes data Data is sent to a transport layer (e.g., Kafka, Kinesis) Data is stored in a database (MySQL, Postgres), data warehouse (Redshift, Snowflake), or data lake (S3, Databricks) Different solutions have different interpretations and implementations of "access control," leading platform teams to implement their own versions. This often results in fragmented implementations across the company. For security engineers, the more fragmented the implementations are, the more difficult it is to implement standardized governance, control, and monitoring, ultimately making the system less secure. Infrastructure/Vendor Auth and Permission Comparison Platform

IAM-Based Auth

Row/Column Permissions



Databricks

Supports IAM-based permissionsLink

Supports row and column-level securityLink



Snowflake

Does not natively support IAM-based permissionsLink

Supports row and column-level security



MySQL

Does not support IAM-based permissions

Supports row and column-level security through grants and policiesLink



PostgreSQL

Does not support IAM-based permissionsLink

Supports row and column-level security Platform

IAM-Based Auth

Row/Column Permissions Databricks

Supports IAM-based permissionsLink

Supports row and column-level securityLink Snowflake

Does not natively support IAM-based permissionsLink

Supports row and column-level security MySQL

Does not support IAM-based permissions

Supports row and column-level security through grants and policiesLink PostgreSQL

Does not support IAM-based permissionsLink

Supports row and column-level security Platform IAM-Based Auth Row/Column Permissions Platform Platform IAM-Based Auth IAM-Based Auth Row/Column Permissions Row/Column Permissions Databricks Supports IAM-based permissionsLink Supports row and column-level securityLink Databricks Databricks Supports IAM-based permissionsLink Supports IAM-based permissions Link Link Supports row and column-level securityLink Supports row and column-level security Link Link Snowflake Does not natively support IAM-based permissionsLink Supports row and column-level security Snowflake Snowflake Does not natively support IAM-based permissionsLink Does not natively support IAM-based permissions Link Link Supports row and column-level security Supports row and column-level security row column-level MySQL Does not support IAM-based permissions Supports row and column-level security through grants and policiesLink MySQL MySQL Does not support IAM-based permissions Does not support IAM-based permissions Supports row and column-level security through grants and policiesLink Supports row and column-level security through grants and policies Link Link PostgreSQL Does not support IAM-based permissionsLink Supports row and column-level security PostgreSQL PostgreSQL Does not support IAM-based permissionsLink Does not support IAM-based permissions Link Link Supports row and column-level security Supports row and column-level security row column-level With data encryption, access is configured once with a crypto key and can then be assigned to individual workloads at different stages of the data flow. This significantly reduces the complexities involved in implementing and aligning permission policies across different platforms. Encryption ensures that data is consistently protected across all platforms, simplifying governance and control while enhancing overall security. Let Keyper Up Your Data Encryption Game Keyper by Jarrid empowers engineering teams to embed data encryption in any data handling process to streamline security implementation. Keyper offers a suite of crypto key management APIs designed to simplify key creation, management, deployment, and encryption/decryption. By integrating with cloud KMS services like AWS KMS and GCP KMS, Keyper enables managed crypto key generation, reducing infrastructure maintenance. This allows organizations to configure encryption once and apply it consistently across all stages of the data flow, ensuring robust security while simplifying governance and operational processes. Keyper by Jarrid

How Data Encryption Can Simplify Infrastructure Architecture

Can Your Java Cryptography Architecture Survive a Quantum Attack?

Stories, News & Mentions about SECURITYPAL

Securitypal’s Stories on HackerNoon