Thursday, 31 May 2018

Keycloak on OpenShift

In this post you'll see how to deploy Keycloak on OpenShift. You'll also learn how to deploy a Node.js based REST service and an HTML5 application to OpenShift and secure these with Keycloak.

There is also a screencast showing this example at https://youtu.be/9zUWqbK3BqI.

If you don't already have OpenShift available a good place to start is by using MiniShift.

Deploying Keycloak

First of all create a new project in OpenShift with oc by running:

oc new-project keycloak

The next thing to do is to import the Keycloak template into OpenShift, by running:

oc replace --force -f "https://raw.githubusercontent.com/jboss-dockerfiles/keycloak"\
"/master/openshift-examples/keycloak-https.json"

Now open the OpenShift console and open the keycloak project.

Click on Add to Project and Browse Catalog. In the catalog you should find Keycloak. Click on it.

Click next on the information. Under configuration set a username and password that you can remember in the Keycloak Administrator Username and Keycloak Administrator Password fields. Then click on create. Click on Continue to project overview.

Wait for the deployment to complete then click on the link to the application. Your browser will complain about the certificate as it is a self-signed certificate. Ignore this and proceed. Click on Administration Console, then login with the username and password you entered previously. Keep this tab open as you will need it later.

You have now deployed Keycloak onto OpenShift.

Configure Clients in Keycloak

We need to create clients for the service and the application we will secure.

Open the tab with the Keycloak admin console. Click on Clients and Create. For Client ID enter service and click Save. Under Access Type select bearer-only and click on Save.

Click on Clients then Create again. For Client ID enter app and click Save. For Valid Redirect URIs and Web Origins enter *. In production environment it is very important that you enter the correct URL for your application, but since this is a demonstration we will simply allow all URLs for simplicity. You can easily update these to the correct URLs for the application after it has been deployed.

Keep the Keycloak admin console tab open as again you will need it later.

Deploy the Service

Go back to the tab with the OpenShift console and click on Add to Project and Browse Catalog again. This time click on Node.js. Click next on Information, then click on advanced options under Configuration.

Make the following changes:

  • Name: service
  • Git Repository URL: https://github.com/stianst/misc.git
  • Context Dir: openshift/service
  • Secure route: enable
  • TLS Termination: Edge
  • Insecure Traffic: Redirect
  • Deployment Config
    • KEYCLOAK_URL=https://secure-keycloak-keycloak.192.168.42.52.nip.io/auth
Replace the value for KEYCLOAK_URL with the URL for Keycloak. You can find this by going back to the tab with the Keycloak admin console (copy the URL up to and including "/auth").

Click on Create then Continue to the project overview. Wait for the build and deployment to complete then click on the link to the application. You should see "Not found!". Add "/service/public" to the url and you should see "message: public" in JSON.

You have now deployed and secured the service. Keep this tab open as well as you need it later.

Deploy the Application

Go back to the tab with the OpenShift console and click on Add to Project and Browse Catalog again. This time click on PHP. Click next on Information, then click on advanced options under Configuration.

Make the following changes:

  • Name: app
  • Git Repository URL: https://github.com/stianst/misc.git
  • Context Dir: openshift/app
  • Secure route: enable
  • TLS Termination: Edge
  • Insecure Traffic: Redirect
  • Deployment Config
    • KEYCLOAK_URL=https://secure-keycloak-keycloak.192.168.42.52.nip.io/auth
    • SERVICE_URL=https://service-keycloak.192.168.42.240.nip.io/service
Replace the value for KEYCLOAK_URL with the URL for Keycloak. You can find this by going back to the tab with the Keycloak admin console (copy the URL up to and including "/auth"). Also, replace the value for SERVICE_URL with the URL for the Service. You can find this by going back to the tab with the service (copy the URL up to and including "/service").

Click on Create then Continue to the project overview. Wait for the build and deployment to complete then click on the link to the application. You should already be logged-in. You can now invoke the service by clicking on Invoke Public to invoke the unsecured endpoint or Invoke Admin to invoke the endpoint secured with the admin role. If you click on Invoke Secured it will fail as the admin user you are logged in with does not have the user role. To be able to invoke this endpoint as well go back to the Keycloak admin console. Create a realm role named user. Then go to users find your admin user and under role mappings add the user role to the user.

You have now deployed and secured the application as well as seen how the application can securely invoke the service you deployed previously.

Thursday, 24 May 2018

Keycloak 4.0.0.Beta3 Released

To download the release go to the Keycloak homepage.

Highlights


Fuse 7 Adapter

There's now support for Fuse 7.

Cordova options in JavaScript adapter

It's now possible to pass Cordova specific options to login and other methods in the JavaScript adapter. Thanks to loorent for the contribution.

Search by user id on admin console

If you wanted to search by a user by id in the admin console you had to edit the URL. It's now possible to do it directly in the user search field.

More...

The full list of resolved issues is available in JIRA.

Upgrading

Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed.

Wednesday, 2 May 2018

Red Hat Single Sign-On @ Red Hat Summit

At Red Hat Summit this year there are no less than 4 sessions about Red Hat Single Sign-On! If you are going to Summit make sure to join us.

OpenShift + single sign-on = Happy security teams and happy users

Dustin Minnich, Joshua Cain, Jared Blashka, Brian Atkisson. Tuesday 4 PM.

One username and password to rule them all.

In this lab, we'll discuss and demonstrate single sign-on technologies and how to implement them using Red Hat products. We'll take you through bringing up an OpenShift cluster in a development environment, installing Red Hat single sign-on on top of it, and then integrating that with a variety of example applications.

Securing service mesh, microservices, and modern applications with JSON Web Token (JWT)

Stian Thorgersen, S├ębastien Blanc. Wednesday 10:30 AM.

Sharing identity and authorization information between applications and services should be done with an open industry standard to ensure interoperability in heterogeneous environments. Javascript Object Signing and Encryption (JOSE) is a framework for securely sharing such information between heterogeneous applications and services.

In this session, we’ll cover the specifications of the JOSE framework, focusing especially on JSON Web Token (JWT). We’ll discuss practical applications of the JOSE framework, including relevant specifications, such as OpenID Connect. After this session, you’ll have an understanding of the specifications and how to easily adopt them using Red Hat single sign-on or another OpenID Connect provider.

Red Hat single sign-on: Present and future

Boleslaw Dawidowicz, John Doyle. Wednesday 3:30 PM.

Red Hat single sign-on (SSO) provides web SSO with modern, token-based protocols, such as OAuth and OpenID Connect. This session will highlight the features of the latest release and show the future direction of the technology within the Red Hat portfolio.

Securing apps and services with Red Hat single sign-on

S├ębastien Blanc, Stian Thorgersen. Thursday 1:00 PM.

If you have a number of applications and services, the applications may be HTML5, server-side, or mobile, while the services may be monolithic or microservices, deployed on-premise or to the cloud. You may have started looking at using a service mesh. Now, you need to easily secure all these applications and services.

Securing applications and services is no longer just about assigning a username and password. You need to manage identities. You need two-factor authentication. You need to integrate with legacy and external authentication systems. Your list of other requirements may be long. But you don’t want to develop all of this yourself—nor should you.

In this session, we’ll demonstrate how to easily secure all your applications and services—regardless of how they're implemented and hosted—with Red Hat single sign-on. After this session, you'll know how to secure your HTML5 application or service, deployed to a service mesh and everything in between. Once your applications and services are secured with Red Hat single sign-on, you'll know how to easily adopt single sign-on, two-factor authentication, social login, and other security capabilities.

Keycloak 4.0.0.Beta2 released

To download the release go to the Keycloak homepage.

Highlights


Pushed Claims

With pushed claims it is now possible for clients to push additional claims to have them used by policies when evaluating permissions.

Resource Attributes

It is now possible to define attributes on resources in order to have them used by policies when evaluating permissions.

Spring Boot 2 support

We now have support for Spring Boot 2.

Instagram identity provider

Thanks to hguerrero it is now easy to enable login with Instagram.

Slovak translation

Thanks to Joe32 we now have Slovak translations.

More...

The full list of resolved issues is available in JIRA.

Upgrading

Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed.