Security

Using Keycloak instead of Picketlink for SAML-based authentication

Using Keycloak instead of Picketlink for SAML-based authentication

sidde3
By Siddhartha De

The Picketlink project is now a deprecated module in Red Hat JBoss Enterprise Application Platform (EAP), so there’s a chance that Picketlink will no longer ship with the next release of EAP/Wildfly and that there will not be any fixes in the near future for the picketlink module.

Picketlink, however, is now merged with Keycloak, an open source identity and access management solution developed by Red Hat’s JBoss Community. In this article, we’ll present an alternative solution to the picketlink module. Some organizations use picketlink as the service provider to enable SAML-based authentication with a third-party identity provider (i.e., Active Directory Federated Services (AD FS), OKTA, PingFederate, etc.). In this, article, we’ll see how the keycloak-saml adapter can be configured in the place of Picketlink to enable SAML-based authentication with a third-party identity provider.

Continue reading “Using Keycloak instead of Picketlink for SAML-based authentication”

Share
Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7

Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7

jorton42
By Joe Orton

Getting an SSL certificate for your web server has traditionally been a something of an effort.  You need to correctly generate a weird thing called a certificate signing request (CSR), submit it to the web page of your chosen Certificate Authority (CA), wait for them to sign and generate a certificate, work out where to put the certificate to configure it for your web server—making sure you also configure any required intermediate CA certificates—and then restart the web server.  If you got all that right, you then need to enter a calendar entry so you’ll remember to go through the process again in (say) a year’s time. Even some of the biggest names in IT can mess up this process.

With new CAs like Let’s Encrypt, along with some supporting software, the rigmarole around SSL certificates becomes a thing of the past.  The technology behind this revolution is Automatic Certificate Management Environment (ACME), a new IETF standard (RFC 8555) client/server protocol which allows TLS certificates to be automatically obtained, deployed, and renewed. In this protocol, an “agent” running on the server that needs an SSL certificate will talk to to the CA’s ACME server over HTTP.

A popular method for using ACME on your Red Hat Enterprise Linux 7 server is certbot. Certbot is a standalone ACME agent that is configured out-of-the-box to work with Let’s Encrypt and can work with Apache httpd, Nginx, and a wide variety of other web (and non-web!) servers.  The certbot authors have an excellent guide describing how to set up certbot with httpd on RHEL7.

In this tutorial, I’ll show an alternative method—the mod_md module—which is an ACME agent implemented as a module for Apache httpd, tightly integrated with mod_ssl, and is supported today in Red Hat Enterprise Linux 7.  The mod_md module was implemented by Stefan Eissing—a prolific developer who also added HTTP/2 support to httpd—and contributed to the Apache Software Foundation, becoming a standard part of any new installation since httpd version 2.4.30.

Continue reading “Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7”

Share
DevNation Live: Easily secure your cloud-native microservices with Keycloak

DevNation Live: Easily secure your cloud-native microservices with Keycloak

editorial-team
By Editorial Team

DevNation Live tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions and code and sample projects to help you get started. In this talk, you’ll learn about Keycloak from Sébastien Blanc, Principal Software Engineer at Red Hat.

Continue reading “DevNation Live: Easily secure your cloud-native microservices with Keycloak”

Share
Using Quay.io to find vulnerabilities in your container images

Using Quay.io to find vulnerabilities in your container images

dtidwell
By Doug Tidwell

You’ve created a container image that has all the packages that you and your team need to do something useful, or maybe you’ve built a public image that anybody can use. But, what if that image contains packages with known security vulnerabilities? Regardless of the severity of those vulnerabilities, you’ll want to learn more and take steps to mitigate them as soon as possible.

Fortunately, your team uses Quay.io* as your registry. When you push an image to Quay.io, it automatically runs a security scan against that image.

Continue reading “Using Quay.io to find vulnerabilities in your container images”

Share
Go and FIPS 140-2 on Red Hat Enterprise Linux

Go and FIPS 140-2 on Red Hat Enterprise Linux

deparker
By Derek Parker

Red Hat provides the Go programming language to Red Hat Enterprise Linux customers via the go-toolset package. If this package is new to you, and you want to learn more, check out some of the previous articles that have been written for some background.

The go-toolset package is currently shipping Go version 1.11.x, with Red Hat planning to ship 1.12.x in Fall 2019. Currently, the go-toolset package only provides the Go toolchain (e.g., the compiler and associated tools like gofmt); however, we are looking into adding other tools to provide a more complete and full-featured Go development environment.

In this article, I will talk about some of the improvements, changes, and exciting new features for go-toolset that we have been working on. These changes bring many upstream improvements and CVE fixes, as well as new features that we have been developing internally alongside upstream.

Continue reading “Go and FIPS 140-2 on Red Hat Enterprise Linux”

Share
Stack Clash mitigation in GCC: Why -fstack-check is not the answer

Stack Clash mitigation in GCC: Why -fstack-check is not the answer

jeffreyalaw
By Jeff Law

In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.

GCC has a capability (-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how -fstack-check works and why it is insufficient for mitigating Stack Clash attacks.

Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”

Share
Five layers of security for Red Hat Data Grid on OpenShift

Five layers of security for Red Hat Data Grid on OpenShift

kashukla
By Kapil Shukla

Red Hat Data Grid is an in-memory, distributed, NoSQL datastore solution. With it, your applications can access, process, and analyze data at in-memory speed to deliver a superior user experience. In-memory Data Grid has a variety of use cases in today’s environment, such as fast data access for low-latency apps, storing objects (NoSQL) in a datastore, achieving linear scalability with data distribution/partitioning, and data high-availability across geographies, among many others. With containers getting more attention, the need to have Data Grid running on a container platform like OpenShift is clear, and we are seeing more and more customers aligning their architecture with a datastore running natively on a container platform.

In this article, I will talk about multiple layers of security available while deploying Data Grid on OpenShift. The layers of security offer a combination of security measures provided by Data Grid as well as by OpenShift/Kubernetes.

Continue reading “Five layers of security for Red Hat Data Grid on OpenShift”

Share
Introduction to using libFuzzer with llvm-toolset

Introduction to using libFuzzer with llvm-toolset

tstellard
By Tom Stellard

“Fuzzing” an application is a great way to find bugs that may be missed by other testing methods. Fuzzers test programs by generating random string inputs and feeding them into an application. Any program that accepts arbitrary inputs from its users is a good candidate for fuzzing. This includes compilers, interpreters, web applications, JSON or YAML parsers, and many more types of programs.

libFuzzer is a library to assist with the fuzzing of applications and libraries. It is integrated into the Clang C compiler and can be enabled for your application with the addition of a compile flag and by adding a fuzzing target to your code. libFuzzer has been used successfully to find bugs in many programs, and in this article, I will show how you can integrate libFuzzer into your own applications.

Continue reading “Introduction to using libFuzzer with llvm-toolset”

Share