This article describes the integration of Red Hat Single Sign-On (SSO) with Red Hat Directory Server 11 (LDAP). It also illustrates how it is possible to perform user synchronization and group synchronization between Red Hat Directory Server and Red Hat’s single sign-on tools.
Continue reading Integrating Red Hat Single Sign-On version 7.4 with Red Hat Directory Server (LDAP)
More and more organizations are using Red Hat Single Sign-On (Red Hat SSO) as the foundation for securing user identities for enterprise and consumer applications. The focus on providing both robust security and a seamless user experience needs to be equally considered. Neither of these requirements should be compromised, especially as applications are being built for a multi-cloud world on Red Hat OpenShift.
Continue reading Extending Red Hat SSO with IBM Security Verify
Red Hat single sign-on (SSO)—or its open source version, Keycloak—is one of the leading products for web SSO capabilities, and is based on popular standards such as Security Assertion Markup Language (SAML) 2.0, OpenID Connect, and OAuth 2.0. One of Red Hat SSO’s strongest features is that we can access Keycloak directly in many ways, whether through a simple HTML login form, or an API call. In the following scenario, we will generate a JWT token and then validate it. Everything will be done using API calls, so Keycloak’s UI is not exposed to the public directly.
When deploying Red Hat Single Sign-On/Keycloak for a test or a proof of concept, most users will choose to use a self-signed certificate as explained in the official documentation.
The setup instructions are straightforward, but this self-signed certificate will trigger certificate error messages in your web browser and can also prevent some clients such as Postman from working properly.
This article explains how to use a public certificate from Let’s Encrypt with Red Hat Single Sign-On.
Continue reading “Using a public certificate with Red Hat Single Sign-On/Keycloak”
In this article I cover configuring NGINX for OAuth-based Single Sign-On (SSO) using Keycloak/Red Hat SSO. This allows the use of OpenID Connect (OIDC) for federated identity. This configuration is helpful when NGINX is acting as a reverse-proxy server for a backend application server, for example, Tomcat or JBoss, where the authentication is to be performed by the web server.
In this setup, Keycloak will act as an authorization server in OAuth-based SSO and NGINX will be the relaying party. We will be using lua-resty-openidc, which is a library for NGINX implementing the OpenID Connect relying party (RP) and/or the OAuth 2.0 resource server (RS) functionality.
Continue reading “Configuring NGINX for OAuth/OpenID Connect SSO with Keycloak/Red Hat SSO”
If you’re looking for a single sign-on solution (SSO) that enables you to secure new or legacy applications and easily use federated identity providers (IdP) such as social networks, you should definitely take a look at Keycloak. Keycloak is the upstream open source community project for Red Hat Single Sign-On (RH-SSO). RH-SSO is a core service that is part of a number of products such as Red Hat JBoss Enterprise Application Platform. If you’ve logged into to developers.redhat.com or openshift.com you are using Keycloak.
On the Red Hat Developer blog there have been a number of recent articles that cover various aspects Keycloak/RH-SSO integration. A recent DevNation Live Tech Talk covered Securing Spring Boot Microservices with Keycloak. This article discusses the features of Keycloak/RH-SSO that you should be aware of.
Continue reading “Single Sign-On Made Easy with Keycloak / Red Hat SSO”
Lets suppose that you have a remote Enterprise JavaBeans (EJB) application where the EJB client is a service pack (SP) application in a Security Assertion Markup Language (SAML) architecture. You would like your remote EJB to be authenticated using same assertion which was used for SP.
Before proceeding with this tutorial, you should have a basic understanding of EJB and Picketlink.
Continue reading “Enabling SAML-based SSO with Remote EJB through Picketlink”
This article discusses how to set up and configure a Keycloak instance to use OpenShift for authentication via Identity Brokering. This allows for Single Sign On between the OpenShift cluster and the Keycloak instance. The Keycloak instance will be running on the OpenShift cluster and leverage a ServiceAccount OAuth Client.
Continue reading “Keycloak Identity Brokering with OpenShift”
Need to lock down your Docker registry? Keycloak has you covered.
As of version 3.2.0, Keycloak has the ability to act as an “authorization service” for Docker authentication. This means that the Keycloak IDP server can perform identity validation and token issuance when a Docker registry requires authentication. Administrators may now leverage the same user base, audit controls, and configuration mechanisms in Keycloak to extend their SSO ecosystem past OpenID Connect and SAML to cover Docker registries. The chart below illustrates how this flow works:
Continue reading “Docker Authentication with Keycloak”
The Azure Openshift 3.6 reference architecture now automatically deploys and integrates SSO. The reference architecture, which is available in a scalable full high-availability configuration and a single vm for trials is part of openshift-ansible-contrib git repo.
Continue reading Openshift 3.6 Reference Architecture Now Includes SSO