In the fast-paced world of business, effective and streamlined processes are the key to success. Salesforce, a powerful customer relationship management (CRM) platform, plays a pivotal role in helping businesses manage and organize their data.

Integrating with Salesforce is essential for businesses aiming to enhance customer relationships, improve efficiency, and gain valuable insights. Salesforce serves as a centralized hub for customer data, enabling organizations to make data-driven decisions, boost sales, and provide exceptional customer experiences.

One crucial aspect of maximizing the potential of Salesforce is automating business processes, and Salesforce Flow is one such robust solution for achieving this goal.

Salesforce Flows offer a declarative and user-friendly way to automate processes. Autolaunch Flows, in particular, can be triggered without user interaction, making them ideal for background processes. Autolaunch Flows can be invoked synchronously providing flexibility in implementation.

Use Case: Daily Reset of Closed Support Tickets Count

Scenario

Imagine a company providing customer support services where support agents resolve customer issues by closing support tickets. The business wants to track and analyze the daily performance of each support agent based on the number of tickets they close. To achieve this, a Salesforce custom field named “Closed Tickets Count” is used to store the total number of closed tickets for each agent.

Requirement

The business has a requirement to reset the “Closed Tickets Count” field to zero at the beginning of each day, ensuring that the daily count reflects the tickets closed on that specific day.

Implementation

To implement this use case, the company can utilize Salesforce Autolaunch Triggers along with Flows. The Autolaunch Flow would be designed to run daily and reset the “Closed Tickets Count” field for all support agents to zero.

Example Field

• Field Name: Closed Tickets Count (custom field on the User object)
• Field Type: Number

Process

The Autolaunch Flow is designed to query and update records based on specified criteria. In this case, it retrieves all user records (support agents) and sets the “Closed Tickets Count” field to zero.

Execution

To ensure that the “Closed Tickets Count” field is reset at the beginning of each day, there are two options.

1. Schedule the trigger to run daily at a specific time
2. Invoke the trigger via the Salesforce REST API which facilitates you to streamline it with your existing business processes.

curl --location '{salesforce_url}/actions/custom/flow/{flow_api_name}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {token}' \
--data '{
    "inputs": [{}]
}'

Result

At the end of each day, the “Closed Tickets Count” field for each support agent is automatically reset to zero, providing a clean slate for tracking the daily performance of support agents in resolving customer issues.

This example demonstrates how a business statistic, in this case, the count of closed support tickets, can be effectively reset daily to provide accurate and up-to-date insights into the daily performance of support agents.

References

Flow Naming Conventions

When it comes to optimizing your application’s performance, both indexing and denormalization are strategies used to enhance the underlying database’s performance, but they address different aspects of database design and usage.

Indexing

Indexes are useful for speeding up SELECT queries by providing a quick lookup mechanism for specific columns. They enhance read performance but can slow down write operations (INSERT, UPDATE, DELETE) as indexes need to be maintained.

Adding indexes to columns that are frequently used in WHERE clauses, JOIN conditions, or ORDER BY clauses can improve query performance. However, adding too many indexes may lead to increased storage requirements and potential overhead during write operations.

Pros

• Facilitate faster data retrieval by allowing the database engine to quickly locate the rows matching specific search criteria, resulting in improved query performance, especially for SELECT operations.
• Enable quicker sorting and grouping of data, making operations like ORDER BY and GROUP BY more efficient.
• Indexes can significantly speed up JOIN operations by providing efficient access paths to the joined tables.
• Indexes can enforce uniqueness constraints on columns, ensuring data integrity and preventing duplicate entries.
• The query optimizer can leverage indexes to generate more efficient query execution plans, leading to overall performance improvements.

Cons

• Consume additional disk space, which can become significant, especially for large tables with multiple indexes.
• They need to be updated whenever data is inserted, updated, or deleted, resulting in additional overhead on write operations (INSERT, UPDATE, DELETE).
• As the number of indexes increases, the overhead on write operations also increases, potentially leading to degraded write performance, especially in write-intensive applications.
• Regular maintenance tasks such as index rebuilds or reorganizations may be necessary to ensure optimal index performance, which can consume system resources and impact overall database maintenance.
• Over time, indexes may become fragmented due to data modifications, leading to suboptimal performance. Regular maintenance is required to address index fragmentation.
• Improper selection of indexes or creating too many indexes can lead to unnecessary overhead and potentially degrade overall database performance. It’s essential to carefully analyze query patterns and usage scenarios to determine the most beneficial indexes.

Denormalization

Denormalization involves storing redundant data in a table to avoid costly JOIN operations, especially in situations where read performance is critical and data modification is infrequent. It is often employed in data warehousing or reporting scenarios.

Denormalization can improve query performance but comes at the cost of increased storage space and potential data inconsistency (due to redundant data). It requires careful management to keep redundant data synchronized.

Denormalization involves storing redundant data in a table to reduce the need for complex JOIN operations and improve query performance.

Pros

• Can significantly enhance read performance, especially in scenarios with complex queries and aggregations.
• Minimizes the need for JOINs, which can be expensive in terms of processing time.

Cons

• Increases storage requirements due to redundant data.
• Requires careful management to ensure data consistency between normalized and denormalized versions.
• Write operations may become more complex and potentially slower.

Factors to consider when deciding

Query Patterns

• If your application has complex queries with multiple JOINs and aggregations, denormalization may be considered to reduce the need for JOINs.
• If your queries involve simple lookups and filtering, indexes might be more suitable.

Write vs. Read Operations

• If your application is write-intensive, adding too many indexes can slow down write operations. In such cases, denormalization might be a better option to optimize read performance.
• If your application is read-intensive and write operations are infrequent, adding indexes may be more beneficial.

Data Modification Frequency

• If your data undergoes frequent updates, inserts, or deletes, excessive indexes may result in overhead during write operations. Denormalization might be preferred in such cases for better write performance.

Storage and Resource Constraints

• Consider the available storage space and system resources. Denormalization increases storage requirements, while indexes consume additional disk space.

Data Consistency Requirements:

• Denormalization may lead to redundancy and potential inconsistencies. If data consistency is crucial, you may need to carefully manage denormalized data or consider alternative solutions.

In many cases, a balanced approach involving a combination of indexing and denormalization might be the most effective solution. It’s important to analyze the specific use case, monitor performance, and iterate on your database design based on actual performance metrics and user requirements.

Subscription-based services have become crucial for businesses these days since they provide a reliable source of revenue while offering convenience to customers. However, managing these subscriptions can become increasingly complex, especially when it comes to handling future changes to subscription plans. Stripe, one of the most powerful payment infrastructures in the world, facilitates this requirement through Stripe Subscription Schedules. In this blog post, we’ll explore how Stripe Schedules can help you automate future changes to subscriptions and enhance your subscription management process.

What are Stripe Schedules?

Stripe Schedules is a feature that allows businesses to automate subscription-related events, such as plan changes, trial periods, and billing cycles, in advance. It offers a straightforward and efficient way to schedule and execute changes to subscriptions without manual intervention, reducing the administrative burden on you and ensuring a seamless experience for your customers.

Common Use-cases of Stripe Schedules

• Schedule subscription activation
• Automate upgrades and downgrades
• Schedule subscription cancellations
• Manage installment plans

A comprehensive list of Stripe Schedule use-cases with sample codes can be found here.

Automating Subscription Upgrades and Downgrades

One of the most common use cases for Stripe Schedules is automating subscription plan changes. Whether a customer wants to upgrade immediately, to a higher-tier plan with additional features or downgrade to a more affordable option on a future date, Stripe Schedules can handle these requests with ease.

For example, if a customer requests a downgrade from a premium plan to a basic plan that starts at the beginning of the next billing cycle, you can set up a schedule to automatically switch their subscription when the next billing period begins. This ensures a smooth transition for the customer and minimizes the chances of manual errors.

Below steps demonstrate how you can integrate with Stripe Schedules API, to schedule a downgrade to be activated on the start date of the next billing period.

1. Generate a Subscription Schedule. You have following 2 options for this.
   *Create a new Subscription with a Schedule.

curl https://api.stripe.com/v1/subscription_schedules \
  -u "sk_test_4eC39HqLyjWDarjtT1zdp7d:" \
  -d customer=cus_GBHHxuvBvO26Ea \
  -d start_date=now \
  -d end_behavior=release \
  -d "phases[0][items][0][price]"=price_1GqNdGAJVYItwOKqEHb \
  -d "phases[0][items][0][quantity]"=1 \
  -d "phases[0][iterations]"=12

* Generate a Subscription Schedule from an existing Subscription.

curl -X POST https://api.stripe.com/v1/subscription_schedules \ 
-u "sk_test_4eC39HqLyjWDarjtT1zdp7dc:" \ 
-d from_subscription=sub_GB98WOvaRAWPl6

2. Fetch the created Subscription Schedule and update it to add an additional phase.

curl -X POST https://api.stripe.com/v1/subscription_schedules/sub_sched_1FSRtAILNmKrzH4z9scwDpeL \
  -u "sk_test_4eC39HqLyjWDarjtT1zdp7dc:" \
  -d "phases[0][plans][0][price]"="price_1GqNdGAJVYItwOKqEHb" \
  -d "phases[0][plans][0][quantity]"=1 \
  -d "phases[0][start_date]"=1577865600 \
  -d "phases[0][end_date]"=1580544000 \
  -d "phases[1][plans][0][price]"="price_1GqNdGAJVYItwOKqEHb" \
  -d "phases[1][plans][0][quantity]"=1 \
  -d "phases[1][iterations]"=1 

Here, we need to pass in two phases in the update request — The first phase should be the existing current phase on the Subscription Schedule. The values should be passed in as it is, without any modifications. The second phase should represent the subscription once it’s been downgraded. iterations set to 1 indicate that the downgrade will be activated on the start date of the next billing cycle.

Depending on your requirements, you can also set proration_behavior, tax_rates and discount_codes

3. In case you want to remove this schedule from the subscription, you can simply release the schedule. This will only cancel the future downgrade.

curl -X POST https://api.stripe.com/v1/subscription_schedules/sub_sched_1OCUR82eZvKYlo2CGBx2JGbV/release \ 
-u "sk_test_4eC39HqLyjWDarjtT1zdp7dc:"

4. In order to view all the schedules of a subscription customer. You can use the below request.

curl https://api.stripe.com/v1/subscription_schedules
-u "sk_test_4eC39HqLyjWDarjtT1zdp7dc:" \
-d "customer=cus_OoOlYtLOckfZc5"

Managing subscriptions and ensuring a smooth experience for your customers can be a challenging task, especially as your business grows. Stripe Schedules offers a solution that streamlines subscription management, automates future changes, and enhances the overall customer experience.

By taking advantage of Stripe Schedules, you can reduce administrative overhead, increase revenue predictability, and minimize errors. Ultimately, this feature allows you to focus on what matters most: growing your business and providing value to your customers.

In this article, I hope to give a step by step approach on how you can secure your Spring Boot application with OpenID Connect Login and Role Based Authorization. I will here be using Keycloak as the Identity Provider however you are free to use another Identity and Access Management Solution in place. The solution given here will work with any other identity provider as well with few changes.

For the scope of this tutorial, I will omit the steps on setting up the Keycloak server and Spring Boot application. I will add links on official guidelines on how you can set up those under References section.

Use case

For simplicity let’s assume we have a Spring Boot application with a Rest Controller to view customers and their payment information. There will be 2 endpoints with GET mapping.

• /customers will list basic information about a customers available in the system. This endpoint allows a user to access customer information with a GET request. We need to ensure security for this endpoint such that only users who successfully authenticated can view the endpoint.
• /payments With this endpoint users can view customer specific payment information. Since this endpoint displays confidential information, we need to enforce an additional level of security. Hence, in addition to having user authentication, we also need to ensure that users with certain privileges (admin access) can view this endpoint data. Therefore, we will be enforcing role based authorization such that only an authenticated user with customer-service-admin role will be allowed to access the endpoint.

Configuring Keycloak for OpenID Connect Login

Create a new realm in your Keycloak server. Let’s use my-realm as the realm name.

Configure a new OpenID Connect client as shown in below image. Let’s use customer-service-client as the Client ID.

Make sure to enable the options ‘Standard flow’ and ‘Client authentication’

Configure a client role from the client role tab. Role name: customer-service-admin

Create 2 new users. Let’s use usernames peter and ben.

For the first user (peter) assign the client role that we created in a previous step.

Navigate to Client Scopes -> Roles -> Client Roles -> Scopes -> Enable the option ‘Add to ID token’

These are the steps required to configure Keycloak for securing your application. Now, if all the configurations are successful, you can try out authorization code flow and obtain an access token from authorization code grant type using a tool like postman or curl and make sure the standard flow is working as expected. If you decode the id_token using a tool like jwt.io, you should be able to find the client roles under the resource_access field in the token as shown below. (When you authenticate with user peter).

Configuring Spring Boot Application

We need to use spring-boot-starter-security and spring-boot-starter-oauth2-client libraries to configure OpenID Connect login for the Spring Boot application. Hence, add the following to your pom file.

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-security</artifactId>
</dependency>

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>

Next, we need to update application.properties file in order to communicate with the Keycloak server using OpenID Connect protocol. Add the below configs to the property file. Make sure to update the values with your application specific settings.

spring.security.oauth2.client.registration.keycloak.client-id=customer-service-client
spring.security.oauth2.client.registration.keycloak.client-secret=cUYL7M81Vm9CKYrxFTqUTtB2FIVqckzM
spring.security.oauth2.client.registration.keycloak.scope=openid,profile,roles
spring.security.oauth2.client.registration.keycloak.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.keycloak.redirect-uri=http://localhost:8001/login/oauth2/code/keycloak
spring.security.oauth2.client.provider.keycloak.issuer-uri=http://localhost:8080/realms/my-realm

Now, we need to override the default HTTP Security configuration in Spring to enforce OpenID Connect Login for the users. This is possible with the registration of a SecurityFilterChain bean as shown below.

@Configuration
@EnableWebSecurity
public class ConfigSecurity {

 @Bean
 public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {

  http.authorizeHttpRequests()
 .requestMatchers("/customers/**").authenticated()
 .and().oauth2Login();
 return http.build();
 }
}

Now if you try to access the /customers endpoint, your browser will be redirected to Keycloak login page. With any of the above created users (peter or ben) you should be able to successfully authenticate.

Next, we need to configure role based authorization for the /payments endpoint as per our second requirement.

Spring internally uses GrantedAuthorities for access control. By default, Spring Framework will generate SimpleGrantedAuthories based on the values available in the ‘scope’ claim of a JWT by prepending them with SCOPE_ prefix. (e.g. SCOPE_openid, SCOPE_email). Those can be used for authorizing requests, such as in hasRole or hasAuthority methods.

In our case, we need a way to extract the client roles from the JWT, and generate GrantedAuthorities for those. For this, I will be implementing a GrantedAuthoritiesMapper as shown below.

public class GrantedAuthoritiesMapperImpl implements GrantedAuthoritiesMapper {

    private static final String RESOURCE_ACCESS = "resource_access";
    private static final String ROLES = "roles";
    private static final String ROLE_PREFIX = "ROLE_";

    @Value("${spring.security.oauth2.client.registration.keycloak.client-id}")
    private String deliveryServiceClientId;

    @Override
    public Collection<? extends GrantedAuthority> mapAuthorities(Collection<? extends GrantedAuthority> authorities) {

        Set<GrantedAuthority> mappedAuthorities = new HashSet<>();

        authorities.forEach(authority -> {
            if (authority instanceof OidcUserAuthority oidcUserAuthority) {
                // Map the claims found in idToken to one or more GrantedAuthority.
                OidcIdToken idToken = oidcUserAuthority.getIdToken();
                mappedAuthorities.addAll(extractClientRoles(idToken));
            }
        });
        return mappedAuthorities;
    }

    private Collection<GrantedAuthority> extractClientRoles(OidcIdToken idToken) {

        Map<String, Object> resourceAccess = idToken.getClaim(RESOURCE_ACCESS);
        Map<String, Object> resource;
        Collection<String> resourceRoles;
        if (deliveryServiceClientId == null || resourceAccess == null
                || (resource = (Map<String, Object>) resourceAccess.get(deliveryServiceClientId)) == null
                || (resourceRoles = (Collection<String>) resource.get(ROLES)) == null) {
            return Set.of();
        }
        return resourceRoles.stream()
                .map(role -> new SimpleGrantedAuthority(ROLE_PREFIX + role))
                .collect(Collectors.toSet());
    }
}

Next, we need to register a bean for the GrantedAuthoritiesMapper class and update the securityFilterChain to enforce Role based Access Control for the /payments endpoint as shown below.

@Configuration
@EnableWebSecurity
public class ConfigSecurity {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {

        http.authorizeHttpRequests()
                .requestMatchers(HttpMethod.GET, "/payments/**").hasRole("customer-service-admin")
                .requestMatchers("/customers/**").authenticated()
                .and().oauth2Login().userInfoEndpoint()
                .userAuthoritiesMapper(this.userAuthoritiesMapper());
        return http.build();
    }
    @Bean
    public GrantedAuthoritiesMapper userAuthoritiesMapper() {
  return new GrantedAuthoritiesMapperImpl();
    }
}

Now if you try to access the /payments endpoint, your browser will be redirected to Keycloak login page as before. But only the user with the admin privileges (peter) will be able to view the contents of this endpoint.

References

• https://www.keycloak.org/docs/18.0/server_installation/
• https://spring.io/guides/gs/spring-boot/

SQL which stands for Structured Query Language is a programming language that was specifically designed to communicate with relational databases. It is a “command” that is sent to the database in order to retrieve a set of records, insert/update records or perform a certain action.

• For example: SELECT name, cost FROM products. This returns the name and cost of all products.
• We can be more specific by adding a WHERE clause: SELECT name, cost FROM products WHERE id = 2. This will return the name and cost of the product with an id equal to 2.

What is an SQL Injection (SQLi) ?

A SQL injection is a technique used to gain unauthorized access to a database by manipulating SQL queries used in an application. Malicious users can use this type of attack to get access to protected resources such as user credentials, or execute malicious SQL statements in order to manipulate the application.

If SQL queries are used in your application in such a way that, an attacker can inject their own SQL into the query, it allows space for SQLi attacks on your application.

Most common way to perform an SQLi on a vulnerable SQL query is to use the UNION clause to combine the results of multiple SELECT statements.

For example assume that following query was used to retrieve the list products from the products table by using the id from a direct user input field of the application.

SELECT name, cost FROM products WHERE id = ? 

An attacker can use the UNION clause in the input field along with the id in order to obtain records from a restricted table in the database.

SELECT name, cost FROM products WHERE id = 2 UNION SELECT username, password FROM users

The above query will combine the two queries and return them in one result set.

+-------------------------+---------------------------+

| name                    | cost                      |

+-------------------------+---------------------------+

| L86 Fingerprint Scanner | 73.55                     |

| user1                   | Secret123                 |

| user2                   | myPaswd                   |

+-------------------------+---------------------------+

This way, an attacker will get the credentials of all the users in the database and he can use those to perform malicious actions on the application.

Testing an Application for SQLi Vulnerability

The best way to test for SQL injections is to follow a structured approach such as follows.

Step 1: Determine number of columns

SQL assumes the select statements on both sides of the UNION clause return the same number of columns. In order to determine how many columns the 1st query uses, we can start with querying for 1 column, then 2 columns etc in the user input field of the application’s page that is susceptible to SQLi. We use numbers so we do not have to guess table names or column names. You keep adding numbers until we see the results of the 1st query on the application page again (make sure no error messages, no empty pages are shown).

• 2 UNION SELECT 1
• 2 UNION SELECT 1,2
• …
• 2 UNION SELECT 1,2,3,4,5

Step 2: Determine location of columns in output

The application now receives the result of the first query and the numbers returned by the second query. Since we’ll never want to look at the results of the first query, we change that first number into a number that never exists: -1

-1 UNION SELECT 1,2,3,4,5

Step 3: Use INFORMATION_SCHEMA to retrieve the column and table names

Now we can simply ask the database to show us all table and column names by using the meta table INFORMATION_SCHEMA.columns!

-1 UNION SELECT 1,table_name,column_name,4,5 FROM INFORMATION_SCHEMA.columns

Note that we still need to match the number of columns with the 1st select statement.

Once we get the list of table names and the column names, we can access data in any of those tables in the database.

Assume the user credentials are available in a table called Users under column names username and password. Then we can list the data as shown below.

-1 UNION SELECT 1,username,password,4,5 FROM Users

How to Prevent SQLi in Your Application?

Following lists some of the techniques you can use to prevent SQLi vulnerabilities in your application. These can be used with any kind of programming language with any kind of database system.

• Using Prepared Statements (with Parameterized SQL Queries)
• Using Properly Constructed Stored Procedures
• Allow-list Input Validation
• Escaping All User Supplied Input

What are the Advantages?

• Facilitates seamless updates to a database schema from one version to another as an application evolves with the code.
• Keeps a record of the updates applied on a schema in a separate table. By default this table is called SCHEMA_VERSION.
• Couple database updates to an application’s deployment pipeline and make sure that those changes are properly applied.
• Keeps track of which changes were already applied and which were not.

In Flyway, updates or changes made to a database schema are known as migrations.

Migration Types

• SQL script based migrations: For straightforward schema changes.
• Java based migrations: For advanced database transformations.

Naming Conventions

Migrations should be named in the default naming conventions for Flyway to identify them properly.

For sql based migrations the naming convention is V<version-number>__<description>.sql

Example: V2__Add_new_table.sql

For Java based migrations, lass name must comply with the pattern V<version-number>__<description>

Example: V2__Add_new_table

Also there are mainly 3 ways to configure and run Flyway for your application

• Integrate flyway directly into your application.
• Run it as a stand-alone tool as part of your build process.
• Execute manually from the command line (using the command line client)

In this post, I will show how you can easily integrate Flyway in to a Java application.

Flyway is implemented in Java and hence the integration is quite straight-forward.

Prerequisites

Configure a database of your own choice. I will be using a MySQL database for this demonstration.

Steps

1. Create a maven based Java project and add the flyway-core dependency under dependencies section in your pom.xml file.

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>8.5.0</version>
</dependency>

2. Inside the build section of POM file, we need to configure the Flyway maven plugin. Also we need to configure the database and Java Connector for the specific database type, as class path dependencies of the plugin.

<plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>8.5.0</version>
    <configuration>
        <url>jdbc:mysql://localhost:3306/flyway_demo</url>
        <user>test</user>
        <password>test</password>
        <locations>
            <location>classpath:db/migration</location>
        </locations>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-mysql</artifactId>
            <version>8.2.2</version>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.12</version>
        </dependency>
    </dependencies>
</plugin>

You need to change the following parameters in the above configuration to suit your integration.

• <url> : This should be your database connection URL.
• <user> : Username for the database connection.
• <password> : Password for the database connection.
• The two dependencies added under <dependencies> section inside the <plugin> should be the database and database Java connector of the particular type of database you are using. I have used the corresponding dependencies to connect to a MySQL database.

3. Create a folder named db.migrations inside src/main/resources folder of your project. Here we will be defining all the migrations. For this project, I will be using SQL script based migrations.

4. Inside db.migrations folder create a new file called V1__add_user_table.sql and add the following code to create our initial table.

create table USER (
    ID int not null,
    NAME varchar(100) not null
);

5. Now execute the following command from the root of your project.

mvn flyway:migrate

6. After the above command is successful, you should be able to see a table called USER created in your database.

7. Let’s add a new migration inside db.migrations with the name V2__add_new_column_email.sql Here we will be altering the schema of the previously created table by adding a new column.

ALTER TABLE USER ADD EMAIL varchar(200);

8. Now when browse the USER table again, you should be able to see that a new column with the title EMAIL is available in the schema.

Similarly, you can add new scripts to modify the schema and insert data to your tables. However make sure to version them properly with the correct naming convention.

I hope you got an idea on what is Flyway and how it can be integrated easily to your project. Here you can refer the complete source code of my project. For additional information you can refer to Official Flyway Documentation.

I was working as a java software engineer for more than 4 years. Recently I joined a firm that uses Kotlin instead of Java and I have been learning Kotlin for the past few weeks.

Learning Kotlin has been fun and interesting. Also, I feel it is fairly easy for a Java developer to learn Kotlin because the syntax is almost similar but Kotlin is less verbose than Java. From my post, I want to share with you some cool features I learned about Kotlin.

Background

Kotlin is an open-source, statically-typed programming language that features both object-oriented and functional programming paradigms. It is the primary development language in Android.

Now let’s dive into some unique features in Kotlin.

Single Type System

A type system is a set of rules that determine the types of a programming language construct.

Kotlin comes along with a very powerful typing system. Unlike Java, Kotlin does not have primitive types. Hence, Kotlin’s type system is solely on objects.

Following are the built-in types in Kotlin.

Other than above, users can define their own types by means of Classes, Interfaces, Enums.

Type Inference

Kotlin is a strongly typed language that supports Type Inference. Kotlin compiler can automatically identify the data type of the variable or the return-type of a function even if you don’t explicitly specify it.

For example, in Kotlin you can declare a variable in 2 ways.

1. var num : Int = 2
2. var num = 2

Note that in the second method, you didn’t have to specify the type of the variable because Kotlin is able to infer the type based on the value assigned to the variable.

This is the same case for the return type of functions.

Smart Casts

Kotlin compiler can perform type casts automatically in the following cases.

• Casting from a supertype to a subtype

val object: Any = "test string"
if(object is String) {
// Here, object is automatically casted to String sub-type.
   println(object.length) 
}

• Casting from nullable types to their non-nullable counterpart

var firstName: String? = "test string"
if(firstName != null) { // Smart cast.
   print(firstName.length)
}

Null safety

In Kotlin, types are non-null by default. To allow a variable to hold null, we can declare a variable with the nullable operator (?).

var firstName: String = null // This will give compilation error

var firstName: String? = null // Ok

Now, Kotlin compiler will warn us whenever we try to access variables declared as nullable.

Elvis Operator

The Elvis operator (?:) is designed specifically to handle null cases. It will return a non-null value or a default value when the variable is null.

val name = firstName ?: "Empty"

You can also throw an exception if the variable is null.

val name = firstName ?: throw Exception("Invalid name")

Top-level Functions & Variables

Top-level functions are functions inside a Kotlin package that are defined outside of any class, object, or interface definition. These functions can be invoked directly, without the reference to a class or an object. Top-level variables are the same as top-level functions. Variables are defined outside a class definition in Kotlin.

fun main() { 
   println("Hello, Kotlin!")
 }

In Kotlin, variables are of two types.

• Read-Only
  val the keyword is used for read-only variables. This is similar to the final keyword in Java meaning the variable cannot be reassigned once initialized.
• Mutable
  var the keyword is used for mutable variables in Kotlin. When a variable is defined as var, it is possible to re-assign its value in a latter part of the code.

Single Expression Definitions

Kotlin gives us the capability to define functions as a single expression for direct operations. Basically, a single-expression function is a function where a single expression is assigned to the function, and the expression’s evaluated value is returned when this function is called.

fun getGreeting() = "Hello, Kotlin"

The above is a single expression function that takes no arguments and return “Hello, Kotlin” string whenever it is called.

String Templates

String templates in Kotlin are String literals that can contain embedded expressions.

val message = "Hello $variable"

Unlike in Java, a String template can contain logic as well.

val message = "Hello, ${if(variable != null) variable else "Unknown"}"

Named Arguments

Kotlin allows you to specify the names of arguments that you’re passing to the function. This can be helpful when a function has many arguments.

fun fun_name(name1: data_type, name2: data_type )

Default Arguments

you can provide default values to parameters in the function definition. When invoking the function, you can omit passing arguments if they are not different from the default ones.

fun printGreeting(greeting:String = "Hello", name:String ="Kotlin") {
   println("$greeting, $name")
}

This allows to configure and re-use functions and objects by leveraging these default and named arguments syntax.

Companion Objects

In the scenario where you do not want to give direct access to the instantiation of a particular class, you can define a companion object inside that class. By declaring a companion object, you can access the properties and functions of the original class using the class name without instantiation. This is useful when implementing the factory design pattern in Kotlin.

class CompanionClass {

    companion object CompanionObject {

    }
}
val object = CompanionClass.CompanionObject

Data classes

Data classes are defined for the purpose of holding data. The Kotlin compiler automatically generates the following functions for them.

• toString()
• equals()
• hashCode()
• copy()
• componentN()

Example of a data class declaration.

data class Employee (
  val id: String,
  val name: String?
)

Extensions

Kotlin provides the ability to extend a class with new functionality without having to inherit from the class. You can extend functions as well as properties of a class.

This is highly useful when you want to incorporate new functions/properties for a class from a third-party library that you cannot modify.

For extending properties, initializers cannot be used. You have to override the getters/setters of those properties. You can also define new properties for existing classes.

Higher-Order Functions

A higher-order function is a function that takes functions as parameters or returns a function. By default, Kotlin functions are first-class. First-class functions can be stored in variables and data structures and can be passed as arguments to and returned from other higher-order functions.

Function Types

In Kotlin, function types are used to store functions as variables. An example is shown below.

val greet = fun() { println("Hello, Kotlin!") }

I hope you got a high-level overview of some of the useful features of Kotlin. For detailed information please refer the official Kotlin documentation. Thank you for reading!

In this post, we’ll discuss the best practices of identifying the authorized user of an access token and what approach we recommend in doing so.

WSO2 Identity Server supports OAuth2 and OpenID Connect frameworks that define standard protocols on authorizing third-party applications when accessing user identities such that access to unauthorized content is restricted.

Within this framework, any third application or a resource server should use a valid token to retrieve user attributes from the authorization server. According to the specification, the user should have given consent for these applications beforehand. The spec suggests the following two approaches on how an application should request user information after a valid access token is acquired from the authorization server.

id-token

Here user needs to authenticate and authorize the application to access his claims. And claims will be sent in the id-token in JWT format, based on the consent given during the authentication process.

user-info endpoint

An application can invoke the user-info endpoint with a valid access token requesting for a set of claims of the user who authorized the token. This token should contain the required scope to access the user claims. The authorization server will consider the token scope, user’s consent and then issue the claim set.

In both of the above methods, the application/resource server gets access to the user’s claims(resources) because the user(resource owner) has provided consent to do or the respective application has the authorization to invoke it.

In addition to spec-compliant approaches, we also provide the capability to retrieve authorized user information via the following approaches.

Token Validation SOAP Service

This was our legacy approach before we had the implementation of user-info endpoint or id-token.

Introspection Endpoint

Here an application authenticates and can retrieve any claim.

Above two options are disabled in the product out of the box. Anyone who needs to enable it should enable the following global config in <IS_HOME>/repository/conf/identity/identity.xml file.

<AuthorizationContextTokenGeneration>

<Enabled>true</Enabled> <TokenGeneratorImplClass>org.wso2.carbon.identity.oauth2.authcontext.JWTTokenGenerator</TokenGeneratorImplClass> <ClaimsRetrieverImplClass>org.wso2.carbon.identity.oauth2.authcontext.DefaultClaimsRetriever</ClaimsRetrieverImplClass><ConsumerDialectURI>http://wso2.org/claims</ConsumerDialectURI><SignatureAlgorithm>SHA256withRSA</SignatureAlgorithm><AuthorizationContextTTL>15</AuthorizationContextTTL>

</AuthorizationContextTokenGeneration>

Why we have disabled it in the product is due to the severe security implications it imposes on WSO2 when it is acting as the authorization server. We do not recommend enabling it as well. I will explain these implications in detail below.

Self-Contained Access Token

This is another way, how an application can obtain user information from token endpoint in the form of a JWT instead of an opaque token. In a self-contained-type, information associated with an access token is embedded in the access token itself in addition to user claims.

Why retrieving user-claims via TokenValidationService/Introspection is NOT recommended?

Introspection endpoint and TokenValidationService can be called by any party who has the authorization to invoke it. But that doesn’t mean they have the authorization to view the particular user’s claims. They are only authorized to see the metadata of the access token.

Therefore if we enable user-claim retrieval via these options, it allows the resource server and any other third-party application who is in possession of a valid access token, to get any claim of the user and there is no restriction. The respective application may not be authorized to do so.

What about self-contained access token?

Here we have a plus point when compared to other two. It is that an application can retrieve user information only after the user successfully authenticates and provides consent to retrieve his claims. However since the token is self-contained and can be verified without invoking the authorization server, there is no way to invalidate the token in case it gets counterfeited, until the token expires.

Due to the above-mentioned implications of these non-standard alternative approaches, we are recommending only the OIDC spec-compliant approaches to retrieve authorized user information of an access token. That is either via the id-token or user-info endpoint.

Thanks for reading!

Best practices in Identifying the Authorization Context of an OAuth2 Token — WSO2 Identity Server was originally published in Identity Beyond Borders on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Helm?

When deploying an application on Kubernetes, it is required to define and manage several Kubernetes resources such as pods, services, deployments, and replicasets. Each of these require to write a group of manifest files in YAML format. In the context of a complex application deployment it becomes a difficult task to maintain several manifest files for each of these resources. Furthermore, templating the manifest files and providing configuration parameters externally, can become crucial which will allow to customize the deployments. Dependency management and version control are some other important factors to consider as well. This is where Helm plays a vital role in automating the process of installing, configuring and upgrading complex Kubernetes applications.

Helm is a package manager for Kubernetes. It allows developers and operators to easily package, configure, and deploy applications and services on Kubernetes clusters. Helm packages contain Kubernetes object definitions. With Helm, configuration settings are isolated from manifest files. This allows to template and customize settings without changing the entire manifest file.

Helm Architecture

Helm uses a packaging format called charts. A chart is a collection of files that describes a related set of Kubernetes resources.

In Helm, there are mainly three notions.

1. chart : A bundle of information necessary to create an instance of a Kubernetes application.
2. config : contains configuration information that can be merged into a packaged chart to create a releasable object.
3. release : A running instance of a chart, combined with a specific config.

Helm is implemented in Go programming language and the same binary executable can function as a client (Helm) or a server (Tiller).

Helm Client

Helm client is a command line tool for managing charts. It’s main functionalities are as follows.

• Developing local charts
• Managing repositories
• Interacting with the Tiller server
• Sending charts to be installed in Kubernetes cluster
• Asking for information about releases
• Requesting upgrading or uninstalling of existing releases in cluster
• Serve local charts via HTTP

Tiller Server

Tiller is the server component of Helm that runs on the Kubernetes cluster. It is responsible for managing releases of helm charts. It interacts with both helm client and interface of Kubernetes API server. It handles the configuration and deployment of Helm releases on the cluster.

Tiller processes a chart to generate Kubernetes resource manifests. Tiller then installs the release into the cluster. Tiller stores each release as a Kubernetes ConfigMap.

Main functionalities are as follows.

• Listening for incoming requests from the Helm client
• Combining a chart and configuration to build a release
• Installing charts into Kubernetes, and then tracking the subsequent release
• Upgrading and uninstalling charts by interacting with Kubernetes

Charts

Helm packages are called charts, and they consist of mainly YAML configuration files. Following is the basic directory structure of a chart.

package-name/
  charts/
  templates/
  Chart.yaml
  LICENSE
  README.md
  requirements.yaml
  values.yaml

You can find an example of above structure in WSO2 Identity Server Helm resources at [1]

These directories and files have the following functions.

• charts/: Manually managed chart dependencies can be placed in this directory. However recommendation is to use the requirement.yaml file to link dependencies dynamically.
• templates/: This directory contains template files that are combined with configuration values. Configuration values can be read from either values.yaml file or command line. These are then rendered into Kubernetes manifests.
• Chart.yaml: A YAML file with metadata about the chart. E.g. chart name, version, maintainer etc.
• LICENSE: A plaintext license for the chart.
• README.md: A readme file which includes the user guide.
• requirements.yaml: A YAML file that lists the chart’s dependencies.
• values.yaml: A YAML file of default configuration values for the chart.

Repositories

A Helm chart repository is an HTTP site that serves an index.yaml file and packaged charts. These files can be served by any web server, object storage service, or a static site host such as GitHub Pages.

Helm comes pre-configured with a default chart repository, identified by the name stable. This repository points to a Google Storage bucket at https://kubernetes-charts.storage.googleapis.com. In addition, you can add any external third party repositories. As such any organization can run an operate its own Helm repository.

Releases

When a Helm chart is deployed in a Kubernetes cluster, it is known as a Helm release. This is an instance of a chart that is running in the cluster. Helm automatically maintains a version history of the releases. We can easily get back to any previous state with helm rollback command. Same chart can be deployed multiple times. This result in multiple releases as well.

[1] https://github.com/wso2/kubernetes-is/tree/master/advanced/is-pattern-1

CSRF (Cross-Site Request Forgery) can allow an attacker to coerce a user into unknowingly and unintentionally dispatch responses to an application. By tricking a user into following a link, for example a link which submits a form to a vulnerable application which does not detect CSRF an attacker can have a user unknowingly perform operations on the application.

Generally, CSRF protection can be provided by the use of a CSRF token. In order to protect against CSRF, this token should be a cryptographically random nonce which is tied to the user’s session. This token can be submitted with the requests as an invisible form field or cookie which ensures that a user cannot submit a form without first visiting the form page. Every request that contain this value must be checked to ensure that it matches the expected value. In the event the value does not match, this can be flagged as suspicious behavior, as it is a clear indication of malicious activities.

In OIDC flow, CSRF attacks can occur against client callback URL when an attacker injects its own authorization code or access token, which can result in the client using an access token associated with the attacker’s protected resources rather than the victim’s. This is described in ‘OAuth 2.0 Threat Model and Security Considerations’ spec [1] as follows.

An attacker could authorize an authorization “code” to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server, and associates the victim’s client session with the resources accessible using the token.

Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker’s resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker’s identity at the external Identity Provider. In this way, the attacker could easily access the victim’s data at the client by logging in from another device with his credentials at the external Identity Provider.

In OIDC flow, ‘state’ parameter is used to mitigate CSRF attacks. In order to prevent CSRF attacks on callback, client needs to implement CSRF protection by checking that the state parameter exists in the user’s session when an authorization code response arrives in exchange for the access token to the client callback URL. The state parameter in this design should a be key to a session attribute in the initiator user’s session with the client application. In typical scenario, this is done by cryptographically binding the value of user’s browser cookie and client ID to session parameter.

However, in the case where OIDC flow is initiated by IDP, IDP cannot prevent the CSRF attacks because the state parameter needs to be generated and managed by the client in order to correlate the state with the application user’s session.

One possible solution which can be performed by the client to mitigate CSRF attacks in IDP initiated OIDC requests, is by verifying the ‘Referer’ headers of the incoming HTTP requests.

This is further elaborated in [2] section 6. Following is an overview of the solution mentioned in the paper.

When the RP receives an authorization response, it first retrieve the identity of the IdP from redirect uri and then checks that the domain in the Referer header is either the RP Domain or the IdP domain. If the domain of the Referer header is one of these two values,then the RP knows this is a genuine authorization response coming from the IdP; otherwise, the RP should discard this HTTP message and send an error page to the user.

As an example of how this might work in practice, suppose a web attacker puts a link https://rp.com/AIdP-callback?code=[code_belongs_to_attacker_generated_by_AIdP] on attacker.com to try to launch a CSRF attack against the redirect uri RP registered with IdP. The HTTP message of the attack re-quest will contain a Referer header which points to attacker.com. The RP is able to detect this is an attack message by comparing the identity of the IdP or its own domain with the domain in the Referer header.

References

[1] https://tools.ietf.org/html/rfc6819#section-4.4.1.8
[2] https://pdfs.semanticscholar.org/03b1/bb33db610486c2f81a2532107b0a17a631ca.pdf