JHipster Roles & Security

---

What is JHipster?

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures with different technology stack for client side and server side and also for microservices and production.

Prerequisites:

For the knowledge of JHipster please read our articles on setup of JHipster.

Summary:

• What is JHipter?
• Prerequisites
• Create new Role in JHipter
• Jhipster Security Overview

Create new Role in JHipter

By default JHipter provides two roles termed as authorities by JHipster ROLE_ADMIN, ROLE_USER in the system. There is one more role ROLE_ANONYMOUSE for actions for anonymous users. We can add more roles along with the existing ones. So let’s add a new role ROLE_SUPER_ADMIN to the system.

Step 1 : Add role constant in AuthoritiesConstants.java file. Also add in other microservices if using for your system in case of need.

public static final String SUPER_ADMIN = "ROLE_SUPER_ADMIN";

Step 2 : Then add the same role in authorities.csv that will reflect in the database while creation of table. It may differ with different databases so add according to the structure of your system. In my case i have configured mysql so updated in the authorities.csv file.

In case you have already created tables, then update the jhi_authorities table with a new super admin role using insert query.

INSERT into jhi_authority (name) VALUES ('ROLE_SUPER_ADMIN');

Jhipster Security Overview

JHipster provides mainly 4 security mechanisms:

1. JSON Web Tokens (JWT)

Now, we have our new role ready to use it as per requirements and also for different access controls such as in the SecurityConfiguration.java or in authorizing the requests or authorizing routes or links/buttons from the client side.

JWT Authentication is a stateless security authentication mechanism that works by a server that generates JWT token containing user’s roles and other required details, sends it back to the client if user credentials are valid, the client stores it locally and passes it to request headers.

JWT is selected by default while creating microservice architecture. By default this is not provided by Spring Security but its a JHipster-specific integration.

There are some configurations for JWT Authentication: The secret key is configured in application-*.yml files.

jhipster.security.authentication.jwt.secret: 
    OR jhipster.security.authentication.jwt.base64-secret:
    

The secret property is less secure and it will show warning while application start-up for not using base64 encoded key and the base64-secret key is more secure because it uses the Base64 encoded string. In case both the properties are used then the secret property will be used.

The secret key should be with a minimum length of 512 bits. The secret key should be kept secret and should change the default user’s password using the change password screen.

2. Session-based authentication

The session based authentication is a stateful session as it uses HTTP Session where the server will create a session after the user logs in and it is stored in a cookie in the user’s browser.

You can configure remember-me authentication using jhipster.security.remember-me.key property in application-*.yml file.
JHipter has an improved remember-me mechanism that provides a unique token which is stored in the database and it also stores extra information such as IP address, browser information, date, etc. to keep track of where the tokens come from.

JHipster stores security information of a user in cookies and also in the database and it alters these values every time a user logs in the system so it helps in cookie theft protection as in case someone uses cookies will be able to use it only once.

JHipster has configured CSRF protection tools for spring security and angular so they can work together.

3. OAuth2 and OpenID Connect

OAuth is an open standard stateful security mechanism used for authorization which anyone can implement and it is a standard that applications can use to provide applications with security. It works over HTTPS and authorizes APIs, servers, applications using access tokens instead of credentials. OAuth comes with two different versions OAuth 1.0a and OAuth 2.0 and both can’t be used together as they are completely different. These days OAuth 2.0 is the most widely used version of OAuth.
Spring Security comes up with outstanding support of OAuth 2.0 and OIDC and is leveraged by JHipster.

• Keycloak

Keycloak is the OpenID Connect server which is by default configured with JHipster. Firstly you will have Keycloak server up and running. JHipster provides docker container for Keycloak with default authorities and users and you can up your server in docker using below command:

docker-compose -f src/main/docker/keycloak.yml up
    

spring:
      security:
        oauth2:
          client:
            provider:
              oidc:
                issuer-uri: http://localhost:9080/auth/realms/jhipster
            registration:
              oidc:
                client-id: web_app
                client-secret: web_app

The required configurations in application-*.yml for security settings are as below:

Add a volume that will be persisted: ./keycloak-db:/opt/jboss/keycloak/standalone/data 
    Change the migration strategy from OVERWRITE_EXISTING, to IGNORE_EXISTING (in the command section)

Keycloak uses by default embedded H2 database so data will get lost on restarting container so try below solution to keep data:

In the prod profile, Keycloak requires you to use HTTPS over HTTP and Keycloak HTTPS provides various ways to achieve it.

• Okta

If using Okta over Keycloak, one will need to modify few things. For that create a free developer account then update configurations in application-*.yml file:

  security:
        oauth2:
          client:
            provider:
              oidc:
                issuer-uri: https://{yourOktaDomain}/oauth2/default
            registration:
              oidc:
                client-id: {client-id}
                client-secret: {client-secret}

Now replace {yourOktaDomain} with organization name eg. aspire.in. Create an ODIC app in Okta through which you will get {client-id} and {client-secret}. For that login to Okta Developer account and go to Applications -> Add Application then click web and then next button. Then after provide app name and provide login redirection URI as http://localhost:8080/login/oauth2/code/oidc and click on done and then http://localhost:8080 as logout redirection URI in your application and also update id and secret of client in application-*.yml file.

Create a group by navigating to Users -> Groups -> Add Group and add existing users or create new to that group. Now go to Api -> Authorization Servers and click default server and click on Claims tab and then Add Claim, give name groups, ID Token for Include in token type, value type as Groups and filter with regex .* and Create and then you are good to go!

Modify JHipster’s Protractor tests to use your account by modifying in below files in case of unit testing :

src/test/javascript/e2e/account/account.spec.ts                                                              and src/test/javascript/e2e/admin/administration.spec.ts.

• HTTPS

You can enforce the use of HTTPS when the application is running on Heroku by below configurations in SecurityConfiguration.java class:

@Configuration 
    public class WebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {            
        `\@Override` 
         protected void configure(HttpSecurity http) throws Exception {     
             http.requiresChannel()
             .requestMatchers(r -> r.getHeader("X-Forwarded-Proto") != null) 
             .requiresSecure(); 
        }
    }

This configuration works on Heroku and Cloud Foundry as well.

4. JHipster User Account and Authentication (UAA)

UAA stands for User Account and Authorization service which secures microservices using OAuth2 authorization server with users and roles and can be built, deployed and run separately in our application. It provides an OAuth2 Authorization server based on Spring Boot, An Identity Management Server for a user account CRUD API.

In order to avoid unwanted access to our resources and APIs, there should be an authorization server that would authorize the request and give access to the resource. If the user is authorized, the client requests the resource with authorization token and gets the requested resource if valid authorization token.

Conclusion

Here we learnt how simple to add new roles in JHipster. With additional roles, we can have greater control over accessing APIs by which users and what data they can see on the client side. JHipster provides 4 different options for security mechanisms and each security mechanism provides different levels of security with different pros and cons. JHipster provides JWT authorization as default security option but we can use any of the security mechanisms as per requirement. For more information please visit JHipter official site

Ready to optimize your JHipster experience?

Contact us for personalized guidance and solutions at [email protected]. Our team at AspireSoftServ is here to ensure your JHipster implementation aligns seamlessly with your unique needs. Elevate your project with tailored JHipster solutions – let's connect and explore the possibilities!

.