Upgrading Spring Security OAuth and JUnit Tests through the ๐ of a Java Hipster
โI love writing authentication and authorization code.โ ~ No Java Developer Ever. Tired of building the same login screens over and over? Try the Okta API for hosted authentication, authorization, and multi-factor auth.
Using unit and integration tests to verify your code quality is an excellent way to show you care about your code. I recently did a bunch of work in the popular JHipster open source project to upgrade it to use the latest release of Spring Security.
Spring Security 5.1+ adds OAuth 2.0 and OIDC as first-class citizens that you can configure with its elegant DSL (a.k.a. cool method chaining, a.k.a. the builder pattern). Iโve been motivated to use it ever since Rob Winch and crew first launched it. Itโs been fun collaborating with them on a very innovative project. Spring Security makes OAuth awesome!
I added OAuth 2.0 support to JHipster in the fall of 2017. The experience influenced me greatly. I learned a ton about Keycloak, Docker Compose, and how to switch between identity providers (IdPs).
I spent the last month upgrading JHipster to use Spring Security 5.1 (the default in Spring Boot 2.1). I experienced some frustrations along the way, shook my fist at Travis CI, and rejoiced when I figured out solutions. I also learned quite a bit in the process. Iโm going to share those experiences with you today.
Logout with OAuth 2.0 and OIDC
Soon after integrating support for Keycloak and Okta in JHipster, the project received a lot of complaints from users that they couldnโt log out. JHipster users were familiar with clicking Logout (check with latest) and being completely logged out. With the default Spring Security support, users would be logged out of the local app, but not the IdP.
It took me a year, but I finally added global SSO logout earlier this year. Both Keycloak and Okta require you to send a GET request to an endpoint with the ID token and the URL to redirect to. Therefore, I created a LogoutResource
that returns these values.
@RestController public class LogoutResource { private final Logger log = LoggerFactory.getLogger(LogoutResource.class); private final UserInfoRestTemplateFactory templateFactory; private final String accessTokenUri; public LogoutResource(UserInfoRestTemplateFactory templateFactory, @Value("${security.oauth2.client.access-token-uri}") String accessTokenUri) { this.templateFactory = templateFactory; this.accessTokenUri = accessTokenUri; } /** * POST /api/logout : logout the current user * * @return the ResponseEntity with status 200 (OK) and a body with a global logout URL and ID token */ @PostMapping("/api/logout") public ResponseEntity<?> logout(HttpServletRequest request, Authentication authentication) { log.debug("REST request to logout User : {}", authentication); OAuth2RestTemplate oauth2RestTemplate = this.templateFactory.getUserInfoRestTemplate(); String idToken = (String) oauth2RestTemplate.getAccessToken().getAdditionalInformation().get("id_token"); String logoutUrl = accessTokenUri.replace("token", "logout"); Map<String, String> logoutDetails = new HashMap<>(); logoutDetails.put("logoutUrl", logoutUrl); logoutDetails.put("idToken", idToken); request.getSession().invalidate(); return ResponseEntity.ok().body(logoutDetails); } }
The Angular client calls the /api/logout
endpoint and constructs the IdP logout URL.
this.authServerProvider.logout().subscribe(response => { const data = response.body; let logoutUrl = data.logoutUrl; // if Keycloak, uri has protocol/openid-connect/token if (logoutUrl.indexOf('/protocol') > -1) { logoutUrl = logoutUrl + '?redirect_uri=' + window.location.origin; } else { // Okta logoutUrl = logoutUrl + '?id_token_hint=' + data.idToken + '&post_logout_redirect_uri=' + window.location.origin; } window.location.href = logoutUrl; });
Testing the LogoutResource
was pretty straightforward. The bulk of the work involved mocking the UserInfoRestTemplateFactory
so it returned an ID token.
@RunWith(SpringRunner.class) @SpringBootTest(classes = JhipsterApp.class) public class LogoutResourceIntTest { @Autowired private MappingJackson2HttpMessageConverter jacksonMessageConverter; private final static String ID_TOKEN = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" + ".eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsIm" + "p0aSI6ImQzNWRmMTRkLTA5ZjYtNDhmZi04YTkzLTdjNmYwMzM5MzE1OSIsImlhdCI6MTU0M" + "Tk3MTU4MywiZXhwIjoxNTQxOTc1MTgzfQ.QaQOarmV8xEUYV7yvWzX3cUE_4W1luMcWCwpr" + "oqqUrg"; @Value("${security.oauth2.client.access-token-uri}") private String accessTokenUri; private MockMvc restLogoutMockMvc; @Before public void before() { LogoutResource logoutResource = new LogoutResource(restTemplateFactory(), accessTokenUri); this.restLogoutMockMvc = MockMvcBuilders.standaloneSetup(logoutResource) .setMessageConverters(jacksonMessageConverter).build(); } @Test public void getLogoutInformation() throws Exception { String logoutUrl = accessTokenUri.replace("token", "logout"); restLogoutMockMvc.perform(post("/api/logout")) .andExpect(status().isOk()) .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8_VALUE)) .andExpect(jsonPath("$.logoutUrl").value(logoutUrl)) .andExpect(jsonPath("$.idToken").value(ID_TOKEN)); } private UserInfoRestTemplateFactory restTemplateFactory() { UserInfoRestTemplateFactory factory = mock(UserInfoRestTemplateFactory.class); Map<String, Object> idToken = new HashMap<>(); idToken.put("id_token", ID_TOKEN); DefaultOAuth2AccessToken token = new DefaultOAuth2AccessToken("my-fun-token"); token.setAdditionalInformation(idToken); when(factory.getUserInfoRestTemplate()).thenReturn(mock(OAuth2RestTemplate.class)); when(factory.getUserInfoRestTemplate().getAccessToken()).thenReturn(token); return factory; } }
I merged global logout support into JHipsterโs master branch in late January, and started upgrading Spring Securityโs OIDC support a few weeks later.
Upgrade Spring Securityโs OIDC Support
I started by creating issue #9276 to track my goals, motivations, and known issues.
At this point, if youโre not intimately familiar with Spring Security, youโre probably wondering: why is upgrading to Spring Securityโs latest release so cool? Long story short: theyโve deprecated annotations, added features, and have made it easier to integrate OAuth 2.0 and OIDC into your applications. Thanks, Spring Security team!
Using @EnableOAuth2Sso and @EnableResourceServer is no longer recommended in Spring Boot 2.1+ (a.k.a., Spring Security 5.1+). The reasons for the change can be found in Josh Longโs Bootiful Podcast, published on Jan 25, 2019. Itโs an interview with Madhura Bhave and the discussion starts at 21:30.
In addition to converting all the Java code and YAML configuration to use the latest Spring Security bits, I also decided to make every JHipster app a resource server by default. Hereโs the logic from JHipsterโs SecurityConfiguration.java.ejs template:
@Override public void configure(HttpSecurity http) throws Exception { // @formatter:off http ... <%_ } else if (authenticationType === 'oauth2') { _%> <%_ if (['monolith', 'gateway'].includes(applicationType)) { _%> .and() .oauth2Login() <%_ } _%> .and() .oauth2ResourceServer().jwt(); <%_ } _%> // @formatter:on } }
To make sure the implementation was OIDC compliant, I overrode the default JwtDecoder
bean with one that does audience validation.
@Value("${spring.security.oauth2.client.provider.oidc.issuer-uri}") private String issuerUri; @Bean JwtDecoder jwtDecoder() { NimbusJwtDecoderJwkSupport jwtDecoder = (NimbusJwtDecoderJwkSupport) JwtDecoders.fromOidcIssuerLocation(issuerUri); OAuth2TokenValidator<Jwt> audienceValidator = new AudienceValidator(); OAuth2TokenValidator<Jwt> withIssuer = JwtValidators.createDefaultWithIssuer(issuerUri); OAuth2TokenValidator<Jwt> withAudience = new DelegatingOAuth2TokenValidator<>(withIssuer, audienceValidator); jwtDecoder.setJwtValidator(withAudience); return jwtDecoder; }
After I had all the runtime code working, I moved onto refactoring tests. Tests are the most reliable indicator of refactoring success, especially with a project that has 26,000 combinations like JHipster does!
I encountered a number of challenges along the way. Since I learned a lot solving these challenges, I thought itโd be fun to explain them and how I solved them.
How to Mock an AuthenticatedPrincipal with an ID Token
The first challenge I encountered was with the updated LogoutResource
. Below is the code after I refactored it to use Spring Securityโs ClientRegistrationRepository
.
@RestController public class LogoutResource { private ClientRegistration registration; public LogoutResource(ClientRegistrationRepository registrations) { this.registration = registrations.findByRegistrationId("oidc"); } /** * {@code POST /api/logout} : logout the current user. * * @param request the {@link HttpServletRequest}. * @param idToken the ID token. * @return the {@link ResponseEntity} with status {@code 200 (OK)} and a body with a global logout URL and ID token. */ @PostMapping("/api/logout") public ResponseEntity<?> logout(HttpServletRequest request, @AuthenticationPrincipal(expression = "idToken") OidcIdToken idToken) { String logoutUrl = this.registration.getProviderDetails() .getConfigurationMetadata().get("end_session_endpoint").toString(); Map<String, String> logoutDetails = new HashMap<>(); logoutDetails.put("logoutUrl", logoutUrl); logoutDetails.put("idToken", idToken.getTokenValue()); request.getSession().invalidate(); return ResponseEntity.ok().body(logoutDetails); } }
I tried to mock out the OAuth2AuthenticationToken
in LogoutResourceIT.java
, thinking this would lead to the AuthenticationPrincipal
being populated.
@RunWith(SpringRunner.class) @SpringBootTest(classes = JhipsterApp.class) public class LogoutResourceIT { @Autowired private ClientRegistrationRepository registrations; @Autowired private MappingJackson2HttpMessageConverter jacksonMessageConverter; private final static String ID_TOKEN = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" + ".eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsIm" + "p0aSI6ImQzNWRmMTRkLTA5ZjYtNDhmZi04YTkzLTdjNmYwMzM5MzE1OSIsImlhdCI6MTU0M" + "Tk3MTU4MywiZXhwIjoxNTQxOTc1MTgzfQ.QaQOarmV8xEUYV7yvWzX3cUE_4W1luMcWCwpr" + "oqqUrg"; private MockMvc restLogoutMockMvc; @Before public void before() { LogoutResource logoutResource = new LogoutResource(registrations); this.restLogoutMockMvc = MockMvcBuilders.standaloneSetup(logoutResource) .setMessageConverters(jacksonMessageConverter).build(); } @Test public void getLogoutInformation() throws Exception { Map<String, Object> claims = new HashMap<>(); claims.put("groups", "ROLE_USER"); claims.put("sub", 123); OidcIdToken idToken = new OidcIdToken(ID_TOKEN, Instant.now(), Instant.now().plusSeconds(60), claims); String logoutUrl = this.registrations.findByRegistrationId("oidc").getProviderDetails() .getConfigurationMetadata().get("end_session_endpoint").toString(); restLogoutMockMvc.perform(post("/api/logout") .with(authentication(createMockOAuth2AuthenticationToken(idToken)))) .andExpect(status().isOk()) .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8_VALUE)) .andExpect(jsonPath("$.logoutUrl").value(logoutUrl)); } private OAuth2AuthenticationToken createMockOAuth2AuthenticationToken(OidcIdToken idToken) { Collection<GrantedAuthority> authorities = new ArrayList<>(); authorities.add(new SimpleGrantedAuthority(AuthoritiesConstants.USER)); OidcUser user = new DefaultOidcUser(authorities, idToken); return new OAuth2AuthenticationToken(user, authorities, "oidc"); } }
However, this resulted in the following error:
Caused by: java.lang.IllegalArgumentException: tokenValue cannot be empty at org.springframework.util.Assert.hasText(Assert.java:284) at org.springframework.security.oauth2.core.AbstractOAuth2Token.<init>(AbstractOAuth2Token.java:55) at org.springframework.security.oauth2.core.oidc.OidcIdToken.<init>(OidcIdToken.java:53) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:172)
I posted this problem to Stack Overflow and sent an email to the Spring Security team as well. Joe Grandja responded with a solution to the problem.
The
AuthenticationPrincipalArgumentResolver
is not getting registered in your test.
It automatically gets registered when the “full” spring-web-mvc is enabled, e.g@EnableWebMvc
.However, in your
@Before
, you have:
MockMvcBuilders.standaloneSetup()
– this does not initialize the full web-mvc infrastructure – only a subset.Try this instead:
MockMvcBuilders.webAppContextSetup(this.context)
– this will registerAuthenticationPrincipalArgumentResolver
and your test should resolve theOidcIdToken
.
Joe was correct. I changed the test to the following and the test passed. โ
@RunWith(SpringRunner.class) @SpringBootTest(classes = JhipsterApp.class) public class LogoutResourceIT { @Autowired private ClientRegistrationRepository registrations; @Autowired private WebApplicationContext context; private final static String ID_TOKEN = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" + ".eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsIm" + "p0aSI6ImQzNWRmMTRkLTA5ZjYtNDhmZi04YTkzLTdjNmYwMzM5MzE1OSIsImlhdCI6MTU0M" + "Tk3MTU4MywiZXhwIjoxNTQxOTc1MTgzfQ.QaQOarmV8xEUYV7yvWzX3cUE_4W1luMcWCwpr" + "oqqUrg"; private MockMvc restLogoutMockMvc; @Before public void before() throws Exception { Map<String, Object> claims = new HashMap<>(); claims.put("groups", "ROLE_USER"); claims.put("sub", 123); OidcIdToken idToken = new OidcIdToken(ID_TOKEN, Instant.now(), Instant.now().plusSeconds(60), claims); SecurityContextHolder.getContext().setAuthentication(authenticationToken(idToken)); SecurityContextHolderAwareRequestFilter authInjector = new SecurityContextHolderAwareRequestFilter(); authInjector.afterPropertiesSet(); this.restLogoutMockMvc = MockMvcBuilders.webAppContextSetup(this.context).build(); } @Test public void getLogoutInformation() throws Exception { String logoutUrl = this.registrations.findByRegistrationId("oidc").getProviderDetails() .getConfigurationMetadata().get("end_session_endpoint").toString(); restLogoutMockMvc.perform(post("/api/logout")) .andExpect(status().isOk()) .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8_VALUE)) .andExpect(jsonPath("$.logoutUrl").value(logoutUrl)) .andExpect(jsonPath("$.idToken").value(ID_TOKEN)); } private OAuth2AuthenticationToken authenticationToken(OidcIdToken idToken) { Collection<GrantedAuthority> authorities = new ArrayList<>(); authorities.add(new SimpleGrantedAuthority(AuthoritiesConstants.USER)); OidcUser user = new DefaultOidcUser(authorities, idToken); return new OAuth2AuthenticationToken(user, authorities, "oidc"); } }
Getting the logout functionality properly tested was a big milestone. I moved on to upgrading JHipsterโs microservices architecture.
How to Pass an OAuth 2.0 Access Token to Downstream Microservices with Zuul
JHipster uses Netflix Zuul to proxy requests from the gateway to downstream microservices. I created an AuthorizationHeaderFilter
to handle access token propagation.
public class AuthorizationHeaderFilter extends ZuulFilter { private final AuthorizationHeaderUtil headerUtil; public AuthorizationHeaderFilter(AuthorizationHeaderUtil headerUtil) { this.headerUtil = headerUtil; } @Override public String filterType() { return PRE_TYPE; } @Override public int filterOrder() { return Ordered.LOWEST_PRECEDENCE; } @Override public boolean shouldFilter() { return true; } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); Optional<String> authorizationHeader = headerUtil.getAuthorizationHeader(); authorizationHeader.ifPresent(s -> ctx.addZuulRequestHeader(TokenRelayRequestInterceptor.AUTHORIZATION, s)); return null; } }
However, adding this did not result in successful access token propagation. With help from Jon Ruddell, I discovered this was because JHipster had a LazyInitBeanFactoryPostProcessor
that caused all beans to be lazy-loaded. The ZuulFilterInitializer
was included in this logic. Making ZuulFilterInitializer
an eagerly-loaded bean caused everything to work as it did before.
At this point, I had everything working, so I created a pull request to upgrade JHipsterโs templates.
I knew that what I checked in required Keycloak to be running for integration tests to pass. This is because of OIDC discovery and how the endpoints are looked up from .well-known/openid-configuration
.
How to Handle OIDC Discovery in Spring Boot Integration Tests
I wasnโt too concerned that Keycloak needed to be running for integration tests to pass. Then some of our Azure and Travis builds started to fail. JHipster developers noted they were seeing errors like the following when Keycloak wasnโt running.
Factory method 'clientRegistrationRepository' threw exception; nested exception is java.lang.IllegalArgumentException: Unable to resolve the OpenID Configuration with the provided Issuer of "http://localhost:9080/auth/realms/jhipster"
I did some spelunking through Spring Securityโs OAuth and OIDC tests and came up with a solution. The fix involved adding a TestSecurityConfiguration
class that overrides the default Spring Security settings and mocks the beans so OIDC discovery doesnโt happen.
@TestConfiguration public class TestSecurityConfiguration { private final ClientRegistration clientRegistration; public TestSecurityConfiguration() { this.clientRegistration = clientRegistration().build(); } @Bean ClientRegistrationRepository clientRegistrationRepository() { return new InMemoryClientRegistrationRepository(clientRegistration); } private ClientRegistration.Builder clientRegistration() { Map<String, Object> metadata = new HashMap<>(); metadata.put("end_session_endpoint", "https://jhipster.org/logout"); return ClientRegistration.withRegistrationId("oidc") .redirectUriTemplate("{baseUrl}/{action}/oauth2/code/{registrationId}") .clientAuthenticationMethod(ClientAuthenticationMethod.BASIC) .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE) .scope("read:user") .authorizationUri("https://jhipster.org/login/oauth/authorize") .tokenUri("https://jhipster.org/login/oauth/access_token") .jwkSetUri("https://jhipster.org/oauth/jwk") .userInfoUri("https://api.jhipster.org/user") .providerConfigurationMetadata(metadata) .userNameAttributeName("id") .clientName("Client Name") .clientId("client-id") .clientSecret("client-secret"); } @Bean JwtDecoder jwtDecoder() { return mock(JwtDecoder.class); } @Bean public OAuth2AuthorizedClientService authorizedClientService(ClientRegistrationRepository clientRegistrationRepository) { return new InMemoryOAuth2AuthorizedClientService(clientRegistrationRepository); } @Bean public OAuth2AuthorizedClientRepository authorizedClientRepository(OAuth2AuthorizedClientService authorizedClientService) { return new AuthenticatedPrincipalOAuth2AuthorizedClientRepository(authorizedClientService); } }
Then in classes that use @SpringBootTest
, I configured this as a configuration source.
@SpringBootTest(classes = {MicroApp.class, TestSecurityConfiguration.class})
Running End-to-End Tests on JHipster Microservices that are Secured with OAuth 2.0
The final issue surfaced shortly after. The jhipster-daily-builds (running on Azure DevOps) were failing when they tried to test microservices.
Caused by: java.lang.IllegalArgumentException: Unable to resolve the OpenID Configuration with the provided Issuer of "http://localhost:9080/auth/realms/jhipster"
We donโt include Keycloak Docker Compose files for microservices because we donโt expect them to be run standalone. They require a gateway to access them, so their OAuth 2.0 settings should match your gateway and the gateway project contains the Keycloak files.
The end-to-end tests that were running on Azure where 1) starting the microservice, and 2) hitting its health endpoint to ensure it started successfully. To fix, Pascal Grimaud disabled starting/testing microservices. He also created a new issue to improve the process so a full microservices stack is generated using JHipsterโs JDL.
Upgrade to Spring Security 5.1 and its First-Class OIDC Support
I hope this list of challenges and fixes has helped you. If youโre using the deprecated @EnableOAuth2Sso
or @EnableResourceServer
, I encourage you to try upgrading to Spring Security 5.1. The issue I used to track the upgrade has links that show all the required code changes.
Use JHipster 6 to Generate a Spring Boot + React app with OIDC for Auth
JHipster 6 uses the latest and greatest versions of Spring Boot and Spring Security. It supports Angular and React for its front-end. It supports Vue too, itโs just not part of the main generator.
If you generate an application with JHipster 6, all of the test features mentioned in this post will be in your application. How do you do that? Iโm glad you asked!
Start by installing a beta of JHipster 6:
npm install -g generator-jhipster@beta
The
npm
command is part of Node.js. Youโll need Node 10.x to install JHipster and run useful commands.
JHipster 6 supports Java 8, 11, and 12 (thanks to Spring Boot 2.1). I recommend managing your Java SDK with SDKMAN! For example, you can install Java 12 and make it the default.
sdk install java 12.0.0-open sdk default java 12.0.0-open
You can create a JHipster app that uses React and OIDC with just a few commands:
mkdir app && cd app echo "application { config { baseName reactoidc, \ authenticationType oauth2, clientFramework react } }" >> app.jh jhipster import-jdl app.jh
Below is a terminal recording that shows the results of these commands.
The configured OIDC provider must be running for a JHipster-generated Spring Boot app to start successfully. You can start Keycloak using Docker Compose:
docker-compose -f src/main/docker/keycloak.yml up -d
Then start your application using Maven:
./mvnw
When startup completes, open http://localhost:8080
, and click sign in. Youโll be redirected to Keycloak, where you can enter admin/admin
to log in.
Why Okta instead of Keycloak?
Keycloak works great, but this is a post on the Okta developer blogs, so let me show you how you can use Okta! Why should you use Okta? Thatโs a great question.
Okta is an always-on identity provider that provides authentication and authorization services for developers. It also allows you to manage your users. I like to call it Users As a Software Service, but UASS isnโt a great acronym. User Management as a Software Service (UMASS) rolls off the tongue a bit easier. Anyway, itโs a great service and you should give it a try.
Register Your Secure Spring Boot Application
To begin, sign up for a free Okta developer account (or sign in if you already have an account).
Once youโre signed in to Okta, register your Spring Boot application.
- In the top menu, click on Applications
- Click on Add Application
- Select Web and click Next
- Enter a Name
- Change the Login redirect URI to be
http://localhost:8080/login/oauth2/code/oidc
- Click Done, then Edit, and add
http://localhost:8080
as a Logout redirect URI - Click Save
Your settings should resemble the screenshot below when youโre finished.
Create an okta.env
file in your projectโs root directory and replace the {..}
values with those from your Okta application:
export SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OIDC_ISSUER_URI=https://{yourOktaDomain}/oauth2/default export SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OIDC_CLIENT_ID={clientId} export SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OIDC_CLIENT_SECRET={clientSecret}
Add
*.env
to your.gitignore
file so this file wonโt end up on GitHub.
Create Groups and Add them as Claims to the ID Token
JHipster is configured by default to work with two types of users: administrators and users. Keycloak is configured with users and groups automatically, but you need to do some one-time configuration for your Okta organization.
Create a ROLE_ADMIN
and ROLE_USER
group (Users > Groups > Add Group) and add users to them. You can use the account you signed up with, or create a new user (Users > Add Person). Navigate to API > Authorization Servers, and click on the the default
server. Click the Claims tab and Add Claim. Name it groups
, and include it in the ID Token. Set the value type to Groups
and set the filter to be a Regex of .*
. Click Create.
Start your application with the following commands:
source okta.env ./mvnw
Navigate to http://localhost:8080
and use your Okta credentials to log in.
Pretty hip, donโt you think?! ๐ค
Better Java Testing with JHipster
JHipster generates an app for you that has good test coverage out of the box. Code coverage is analyzed using SonarCloud, which is automatically configured for you. Run the following command to start Sonar in a Docker container.
docker-compose -f src/main/docker/sonar.yml up -d
Then run the following Maven command:
./mvnw -Pprod clean test sonar:sonar -Dsonar.host.url=http://localhost:9001
Once the process completes, navigate to http://localhost:9001/projects
and youโll see your projectโs report.
The code coverage is much higher than whatโs shown in this report. We changed many tests to run in the integration test phase recently, and havenโt figured out how to report this data to Sonar.
See JHipsterโs Code Quality documentation for more information about this feature.
Support for JUnit 5 in JHipster is also in the works.
Learn More about Spring Security, Spring Boot, and JHipster
I hope youโve enjoyed my story about upgrading JHipster to use Spring Security 5.1 and its stellar OAuth 2.0 + OIDC support. I really like what that Spring Security team has done to simplify its configuration and make OIDC discovery (among other things) just work.
I did not create a GitHub repository for this example since JHipster generated all the code and I didnโt need to modify anything.
If youโd like to learn more about JHipster 6, see Better, Faster, Lighter Java with Java 12 and JHipster 6. If youโre interested in JHipsterโs CRUD generation abilities and PWA support, I encourage you to check out my blog post on how to build a Photo Gallery PWA with React, Spring Boot, and JHipster.
Weโve also published a number of posts about testing and Spring Security 5.1:
- Test Your Spring Boot Applications with JUnit 5
- The Hitchhikerโs Guide to Testing Spring Boot APIs and Angular Components with WireMock, Jest, Protractor, and Travis CI
- A Quick Guide to OAuth 2.0 with Spring Security
- Migrate Your Spring Boot App to the Latest and Greatest Spring Security and OAuth 2.0
Want more tech tips? Follow us on social networks { Twitter, LinkedIn, Facebook, YouTube } to be notified when we publish new content.
Have a question about Okta thatโs unrelated to this post? Please ask it on our developer forums.
“Upgrading Spring Security OAuth and JUnit Tests through the of a Java Hipster” was originally published on the Okta developer blog on April 15, 2019.
โI love writing authentication and authorization code.โ ~ No Java Developer Ever. Tired of building the same login screens over and over? Try the Okta API for hosted authentication, authorization, and multi-factor auth.