Securing web applications and services with Red Hat Single Sign-On

Configuring the Realm, roles, groups and users

Before proceeding with the next sections, we need to configure the realm, roles and users in our Red Hat Single Sign-On instance.

Open a browser window and log in to the Red Hat Single Sign-On administration web console.
Create the demo realm. Click on the Add realm button, provide the realm name, and click Create.

Create the staff group. Click on Groups.

Then click New.

Set staff as the group name, and click Save.

Create the subgroup named Personal staff. Click on Groups, select the staff group, and click New.

Set Personal staff as the name, and click Save.

Create the role vet. Click on Roles, then Add Role.

Set the Role name, and click Save.

Repeat the same steps for creating a role named assistant.
Create the user angel. Click on Users, then Add user.

Set the username, and click Save.

Open the Credentials tab and set the password for the user. Make sure to set Temporary to OFF before setting the password.

Open the Role Mappings tab and assign the vet role to the user.

Open the Groups tab and assign the user angel to the Personal staff group by clicking the group and the Join button.

Repeat the same steps for creating a user named elisabeth but assign the assistant role. Also, remember to incude the user in the Personal staff group.

Red Hat Single Sign-On allows defining one or more groups as default groups, where any new user will automatically join the defined groups, making it easier to assign users to the same group without repetitive and time-consuming tasks. The option is available by clicking on Groups, then Default Groups.

Securing Quarkus web applications using OpenID Connect (OIDC)

The sample application that we will use in this section is the Quarkus Petclinic project.

In this tutorial, we will work with a version that has been modified for the tutorial.

The repository for this modified version is:

https://github.com/aolle/quarkus-petclinic.git

To get started, clone the repository and switch to the rh-sso-base-7.6 branch:

git clone -b rh-sso-base-7.6 https://github.com/aolle/quarkus-petclinic.git

The application is prepared to be deployed on top of Red Hat OpenShift. The application project contains the Quarkus OpenShift extension (k8s with s2i) to automatically generate the OpenShift resources and deploy it.

Test the application, follow these steps:

Log into your Red Hat OpenShift cluster.
Switch to the sso project if you are not currently using it.
Deploy the application by executing the ocp-deploy.sh script or alternatively:

./mvnw install -Dquarkus.kubernetes.deploy=true

During the build, you may encounter the SSLHandshakeException/ValidatorException exception due to self-signed certificate. To solve this, add -Dquarkus.kubernetes-client.trust-certs=true during the build process.

Open a browser window and visit the application URL.

Make a note of the application URL as it will be required during the security configuration process.

Before securing the application, let’s configure a new client in our Red Hat Single Sign-On realm.

Open a browser window and log in to the Red Hat Single Sign-On administration web console.
Select our demo realm and click Clients. Click Create.

Set quarkus-petclinic as Client ID. Click Save.

On the quarkus-petclinic client configuration page:
- Change the Access Type from public to confidential.
- Set Authorization Enabled to ON.
- Set Valid Redirect URIs to include the root context of your application. For example, if your petclinic application is available at http://domain.example.com/, write http://domain.example.com/*.
- Click Save.

At this point, we have the demo realm with the quarkus-petclinic client; additionally, we created two roles and two users: the user angel that has the vet role and the user elisabeth that has the role assistant.

The authorization granularity that we want to configure based on our application is the following:
- Any user that belongs to the demo realm, like elisabeth, can browse the application except the VETERINARIANS resource.
- Only the users with the role vet can view the VETERINARIANS resource (which has the /vets.html context).
- Any other user access outside the realm will be rejected.

Let’s configure our client authorization.

Open a browser window and log in to the Red Hat Single Sign-On administration web console. Browse to our quarkus-petclinic client and click the Authorization and then Resources tabs.

Click Create Permission for the Default Resource.

quarkus petclinic auth create permission default

Click on Create Policy… and select Group.

Set Default Group Policy as the Name. Select staff from the Groups list and click Select. Make sure that the Logic is set to Positive and Extend to Children is checked (we will use this logic in later chapters). Finally, click Save.

You will be redirected back to the Add Resource Permission page. Set Default Resource Permission as Name and select Default Resource as Resources. The recently created policy should have been added automatically. Click Save.

quarkus petclinic default resource permission

Create a new resource by clicking on Create.

Set Vets Resource as Name and Display name, and /vets.html as URI. Click Save.

Browse to Authorization and Policies tabs. Click on Create Policy… and select Role.

Set Vet Role Policy as the Name, vet as Realm Roles, and check required. Click Save.

Browse to the Authorization and Resources tabs.
Click on Create Permission for the Vets Resource.

Set Vets Resource Permission as Name. And apply the Vet Role Policy. Click Save.

At this point, the Red Hat Single Sign-On client is properly configured.

Let’s configure the application side.

Open a browser window and log in to the Red Hat Single Sign-On administration web console. Browse to our quarkus-petclinic client and click the Credentials tab. Write down the Secret value, we will need it soon.

Create the ConfigMap with the SSO_HOST environment variable. Replace {YOUR_SSO_HOST} with the correct value.

oc create configmap quarkus-petclinic-config --from-literal=SSO_HOST={YOUR_SSO_HOST} -n sso

Create the secret with the OIDC client credentials. Replace the {YOUR_SSO_CLIENT_SECRET} with the correct value.

oc create secret generic quarkus-petclinic-secret --from-literal=SSO_CLIENT_SECRET={YOUR_SSO_CLIENT_SECRET} -n sso

Add the following configuration in application.properties as shown:

quarkus.openshift.env.secrets=quarkus-petclinic-secret
quarkus.openshift.env.configmaps=quarkus-petclinic-config

quarkus.oidc.auth-server-url=https://${SSO_HOST:localhost:8080}/auth/realms/demo
quarkus.oidc.client-id=quarkus-petclinic
quarkus.oidc.credentials.secret=${SSO_CLIENT_SECRET:secret}
quarkus.oidc.tls.verification=none
quarkus.oidc.roles.source=accesstoken

quarkus.oidc.application-type=web-app
quarkus.oidc.webapp.auth-server-url=${quarkus.oidc.auth-server-url}
quarkus.oidc.webapp.client-id=${quarkus.oidc.client-id}
quarkus.oidc.webapp.credentials.secret=${quarkus.oidc.credentials.secret}
quarkus.oidc.webapp.roles.source=${quarkus.oidc.roles.source}

quarkus.keycloak.policy-enforcer.enable=true

Redeploy and test the application accesses:
- Open a new incognito browser session.
- Browse to the context root of the Quarkus Petclinic application. The request will be redirected to the Red Hat Single Sign-On login page. Here, we checked that the anonymous access to the application is forbidden.
- Log in as elisabeth. The request will be redirected to the application after a successful login.
- Browse through the application, try to access the VETERINARIANS section. The access should be denied, as elisabeth has the assistant role and the access is restricted to the vet role. An error will be shown on the application page.
- Close the browser and open a new one incognito session.
- Visit the context root of the application again.
- Login as angel.
- Browse through the application, try to access the VETERINARIANS section. The access should be granted, as angel has the vet role.

A complete OIDC working Petclinic Quarkus application is available at rh-sso-oidc-7.6 branch.