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”
Red Hat 3scale API Management Platform simplifies the integration between APIcast gateway and Red Hat Single Sign-On through OpenID Connect (OIDC) for API authentication. Consequently, the new version enables API provider users to select and configure their API authentication process from the Admin Portal UI.
Continue reading “3scale API Management Simplifies OpenID Connect Integration”
In this post, I will provide a walk through of how to set up Identity Brokering on an RH-SSO server.
Red Hat Single Sign-On (RH-SSO) provides Web single sign-on and identity federation based on SAML 2.0, OpenID Connect and OAuth 2.0 specifications.
For this tutorial, you will need:
- An RH-SSO Instance.
- A Web/Mobile Application with an OpenID Connect adapter.
- An OpenID Connect Provider Server (Such as Keycloak) to be used as the 3rd Party Identity Provider.
Continue reading “OpenID Connect Identity Brokering with Red Hat Single Sign-On”
I am pleased to announce the immediate availability of Red Hat Software Collections 3.0 Beta, Red Hat’s newest installment of open source development tools, dynamic languages, databases, and more. Delivered on a separate lifecycle from Red Hat Enterprise Linux with a more frequent release cadence, Red Hat Software Collections bridges development agility and production stability by helping you create modern applications that can be confidently deployed into production. Most of these components are also available in Linux container image format to streamline microservices development.
In addition to these new components having traditional support for x86_64, Red Hat Software Collection 3.0 Beta adds support for three new architectures: s390x, aarch64, and ppc64le.
NEW ADDITIONS to Red Hat Software Collections 3.0 Beta include:
Continue reading “Red Hat updates Python, PHP, Node.js, more; supports new arches”
The tutorial Spring Boot and OAuth2 showed how to enable OAuth2 with Spring Boot with Facebook as AuthProvider; this blog is the extension of showing how to use KeyCloak as AuthProvider instead of Facebook. I intend to keep this example as close to the original Spring Boot and OAuth2 and will explain the changes to the configuration to make the same application work with KeyCloak. The source code for the examples are available in the github repositories listed below.
Continue reading Spring Boot and OAuth2 with Keycloak
Microservices are currently enjoying immense popularity. It is rare to find a tech conference without at least a few mentions of them in corridor conversations or titles of talks, and for good reason: microservices can provide a path to better, more maintainable, higher quality software delivered faster. What’s not to love?
Of course there are the “negatives” and details in the implementation of microservices that can trip up even the most seasoned architect-developer, but at the same time we are collectively learning from mistakes and creating or reusing fantastic open source projects and products that can help smooth over those rough bits.
One such project is Apache Camel (and Fuse, its Red Hat-supported distribution.) Created way before the microservices revolution, Apache Camel was born to ease integration of disparate computing systems by implementing well-tested enterprise integration patterns (EIPs) and supplying a developer-friendly interface for writing code to do the integration.
Continue reading “Microservices: Comparing DIY with Apache Camel”
Red Hat, Inc. recently released the Red Hat SSO product, which is an enterprise application designed to provide federated authentication for web and mobile applications.
In the SAML world, RH SSO is known as an Identity Provider (IdP), meaning its role in life is to authenticate and authorize users for use in a federated identity management system. For example, it can be used to authenticate internal users against a corporate LDAP instance such that they can then access the corporate Google Docs domain.
Red Hat IT recently re-implemented our customer-facing authentication system, building the platform on Red Hat SSO. This system serves all Red Hat properties, including www.redhat.com and access.redhat.com — our previous IdP was a custom-built IdP using the JBoss EAP PicketLink framework.
While this worked for the original SAML use-case, our development teams were seeking an easier integration experience and support for OAuth and OpenID Connect protocols. Red Hat SSO comes out of the box with full SAML 2.0, OAuth 2.0 and OpenID Connect support. Re-implementing the IdP from the ground-up gave us a chance to re-architect the solution, making the system much more performant and resilient. While outages were never really acceptable in the past, our customers now expect 24/7 uptime. This is especially true with Red Hat’s increased product suite, including hosted offerings such as OpenShift Online.
Continue reading “How Red Hat re-designed its Single Sign On (SSO) architecture, and why.”