DevNation Tech Talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions plus code and sample projects to help you get started. In this talk, you’ll learn about Keycloak from Stian Thorgersen and Burr Sutter.
Continue reading A deep dive into Keycloak
What if you needed to provide authentication to several microservices that were written in different languages? You could use Red Hat Single Sign-On (SSO) to handle the authentication, but then you would still need to integrate each microservice with Keycloak. Wouldn’t it be great if a service could just handle the authentication flow and pass the user’s details directly to your microservices? In this article, I introduce a service that does just that!
Continue reading Authorizing multi-language microservices with Louketo Proxy
Open Liberty 20.0.0.7 lets you disable the default of returning Lightweight Third-Party Authentication (LTPA) cookies for authentication when using Trust Association Interceptor (TAI) or Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) authentication. You can also disable JSON Web Token (JWT) cookies when using JWT’s single sign-on (SSO) feature. In this article, we introduce these improvements and more in the new Open Liberty 20.0.0.7 release:
Continue reading Flexible single sign-on authentication and more in Open Liberty 20.0.0.7
One of the luxuries of my job is that I get to speak to and work with a range of IT people employed by U.S. federal and state government agencies. That range includes DevOps engineers, developers, sysadmins, database administrators, and security professionals. Everyone I talk to, even security professionals, says that IT security and compliance can be imprecise, subjective, overwhelming, and variable—especially in the federal government.
Continue reading What enterprise developers need to know about security and compliance
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
You might not need Secure Socket Layer (SSL)-based communication between microservices in the same cluster, but it’s often a requirement if you want to connect to a remote web service or message broker. In cases where you will expose a web service or other endpoints, you might also have to use a custom keystore in a microservice deployed on Red Hat OpenShift, so that external clients only connect with a specific truststore.
In this article, I show you how to configure a keystore and a truststore for a Java-based microservice built with Spring Boot. I used the Apache Camel and CXF libraries from Red Hat Fuse to develop the microservice. I used a source-to-image (S2I) deployment and tested the examples in Red Hat OpenShift 4.3.
Continue reading “Adding keystores and truststores to microservices in Red Hat OpenShift”
In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing -fstack-check mechanism is insufficient for protection.
So, what should we do? Clearly we want something similar to -fstack-check, but without the fundamental problems. Enter a new option: -fstack-clash-protection.
The key principles for code generation to prevent a stack clash attack are:
Continue reading “Stack clash mitigation in GCC, Part 3”
I work at Red Hat on GCC, the GNU Compiler Collection. For the next major release of GCC, GCC 10, I’ve been implementing a new -fanalyzer option: A static analysis pass to identify various problems at compile-time, rather than at runtime.
My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary). Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees—because it is the compiler.
Continue reading “Static analysis in GCC 10”
This article demonstrates the use of multiple vault passwords through vault IDs. You will learn how to use vault IDs to encrypt a file and a string. Once they’re encrypted, the vault ID can be referenced inside a playbook and used within Red Hat Ansible and Red Hat Ansible Tower.
Vault IDs help you encrypt different files with different passwords to be referenced inside a playbook. Before Ansible 2.4, only one vault password could be used in each Ansible playbook. In effect, every file needed to be encrypted using the same vault password.
To begin with, vault IDs need to be pre-created and referenced inside your ansible.cfg file. The following excerpt is from ansible-config list for the configuration DEFAULT_VAULT_IDENTITY_LIST:
Continue reading “Vault IDs in Red Hat Ansible and Red Hat Ansible Tower”
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.
Continue reading “API login and JWT token generation using Keycloak”
