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.

Set up the Relying Party

Select AD FS profile for SAML2.0 based federation:

If you are required to enable encrypted assertion, import the certificate that will be used for encryption, but make sure that the associated private key is present with the service provider.

Check the SAML2.0 WebSSO protocol support to enable SAML federation with a web application:

Add the URL of the relying party trust; multiple URLs can be added here:

Permit all users to enable access for all the user to the relying-party:

Once the relying party trust is added, AD FS will be able to correctly authenticate the users according to requests from the service provider, but the requested name ID format will not yet be recognized and the SAML response will not contain any additional information like email. Thus, it’s necessary to map claims from AD user details into a SAML document.

Three rules

We will set up three rules: one for mapping user ID, one for mapping standard user attributes, and another for a user group. All of these start by clicking the Add Rule button in the Edit Claim Rules.

The first rule will map the user ID in Windows Qualified Domain name to the SAML response. In the Add Transform Claim Rule window, select Transform an incoming claim rule type:

The second rule will map the user email to the SAML response. In the Add Transform Claim Rule window, select Send LDAP attributes as Claims rule type. You can add other attributes as needed:

• Download the Wildfly client adapter from https://www.keycloak.org/downloads.html.
• Unzip the saml-adapter at $Wildfly_Home. In Linux, unzip can be done by executing the command unzip keycloak-wildfly-adapter-dist.zip.
• Post successful extraction a CLI script. adapter-install-saml.cli will be present at $Wildfly_Home/bin, which is required to be executed through the jboss-cli command, i.e., $Wildfly_Home/bin/jboss-cli.sh --connect --file=adapter-install-saml.cli.

<keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter" 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="urn:keycloak:saml:adapter 
               http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd">
      <SP entityID="https://example.com:8443/saml-servlet-filter/" sslPolicy="EXTERNAL"
           nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName"
           logoutPage="/logout.jsp">
           <IDP entityID="idp" signatureAlgorithm="RSA_SHA256">
                <SingleSignOnService signRequest="false"
                        validateResponseSignature="false"
                        requestBinding="POST"
                        bindingUrl="https://example.adfs.com/adfs/ls/"/>
                <SingleLogoutService signRequest="false"
                        signResponse="false"
                        validateRequestSignature="false"
                        validateResponseSignature="false"
                        requestBinding="POST"
                        responseBinding="POST"
                        postBindingUrl="https://example.adfs.com/adfs/ls/"
                        redirectBindingUrl="https://example.adfs.com/adfs/ls/"/>
          </IDP>
      </SP>
</keycloak-saml-adapter>

The post Using Keycloak instead of Picketlink for SAML-based authentication appeared first on Red Hat Developer.

Enterprise JavaBeans (EJB) has been very important to the Java EE ecosystem and promoted many robust solutions to enterprise problems. Besides that, in the past when integration techniques were not so advanced, EJB did great work with remote EJB, integrating many Java EE applications. However, remote EJB is not necessary anymore, and we have many techniques and tools that are better for doing that. So, does EJB still have a place in this new cloud-native world?

Before writing this post, I did an informal survey via Twitter poll to hear what the community thinks about it. In this article, I’ll share the results of the survey as well as some discussion that emerged as part of the poll. Additionally, I’ll share my opinions on the topic.

Twitter survey

Here is the question I asked in the survey along with the results (from 385 respondents):

We had many changes in the Java ecosystem mainly in Java enterprise. But what do you think about the EJB future? Do you think EJB has its place in this new cloud-native world? 

1. Yes, but needs updates …..29%
2. No, EJB is unnecessary ….50%
3. Yes, it’s very useful …………17%
4. Other ……………………………..4%

As you can see, option 2 is the winner, and the majority of respondents think EJB is unnecessary. However, it’s the winner with 50% of the vote, which means that 50% of respondents think EJB is necessary in some way or have some other opinion. That’s not the only interesting thing in this survey, though; the other interesting thing was the discussion emerged from this survey about getting the interesting features from EJB and distributing them to other specs with more affinity. But before we get into this discussion, I’ll share my opinion and explain why I think this.

My vote

My vote is for option 1 (Yes, but needs updates), because although EJB is an old technology, it has many features that are useful to the enterprise environment. But EJB can be sanitized to offer these features in a lighter technology. Here’s a list of EJB’s interesting features:

• Asynchronous invocation: Is useful when you want to make a non-blocking call to some method.
• Stateless EJBs pool: Optimizes memory use, promoting reuse of stateless EJB objects.
• @Startup to call a method at startup time: Is useful when we want to execute something at startup time.
• EJB timer: Is a good feature to schedule a process to execute according to some configuration.
• Singleton: Is useful when we want only one instance of an object to all applications. Furthermore, it has the method lock feature that is useful when we need to control concurrent access to some method.
• Message-driven bean (MDB): Is very useful to consume JMS queues and topics. It promotes a simple interface with a high level of abstraction to consume JMS.
• Transaction management: Is useful to manage transactions with databases and resources (like JMS). It promotes a high level of abstraction to work with transnational processes.

These features are useful to the current scenario of the enterprise world, and having these features in a spec-based solution is good for the Java ecosystem. Many people have noted that Spring and other frameworks already have these features, but they are important features to have in a spec-based solution (like Jakarta EE) as well, because spec solutions are multi-vendor solutions and not coupled with a specific vendor.

Conclusion

The interesting EJB features should survive, whether they have the EJB name or not. The idea of getting the interesting features from EJB and distributing them to other specs with more affinity is amazing and means we will have these important features in the Jakarta EE, but in lighter and more organized APIs. This is a good chance to evolve the Jakarta EE feature set to promote lighter, more cohesive Jakarta EE components and APIs.

The post Jakarta EE: What’s in store for Enterprise JavaBeans? appeared first on Red Hat Developer.

JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 for Eclipse 2019-09 are here and waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.

Installation

Red Hat CodeReady Studio (previously known as Red Hat Developer Studio) comes with everything pre-bundled in its installer. Simply download it from our Red Hat CodeReady Studio product page and run it like this:

java -jar codereadystudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) CodeReady Studio requires a bit more.

This release requires at least Eclipse 4.13 (2019-09), but we recommend using the latest Eclipse 4.13 2019-09 JEE Bundle because then you get most of the dependencies pre-installed.

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under “JBoss Tools” or “Red Hat CodeReady Studio.”

For JBoss Tools, you can also use our update site directly:

http://download.jboss.org/jbosstools/photon/stable/updates/

What’s new?

Our main focus for this release was improvements for container-based development and bug fixing. Eclipse 2019-06 itself has a lot of new cool stuff, but I’ll highlight just a few updates in both Eclipse 2019-06 and JBoss Tools plugins that I think are worth mentioning.

Red Hat OpenShift

OpenShift Container Platform 4.2 support

With the new OpenShift Container Platform (OCP) 4.2 now available (see the announcement), even if this is a major shift compared to OCP 3, Red Hat CodeReady Studio and JBoss Tools are compatible with this major release in a transparent way. Just define your connection to your OCP 4.2 based cluster as you did before for an OCP 3 cluster, and use the tooling!

CodeReady Containers 1.0 Server Adapter

A new server adapter has been added to support the next generation of CodeReady Containers 1.0. Although the server adapter itself has limited functionality, it is able to start and stop the CodeReady Containers virtual machine via its crc binary. Simply hit Ctrl+3 (Cmd+3 on OSX) and type new server, which will bring up a command to set up a new server.

Enter crc in the filter textbox.

You should see the Red Hat CodeReady Containers 1.0 server adapter.

Select Red Hat CodeReady Containers 1.0 and click Next.

All you have to do is set the location of the CodeReady Containers crc binary file and the pull secret file location, which can be downloaded from https://cloud.redhat.com/openshift/install/crc/installer-provisioned.

Once you’re finished, a new CodeReady Containers server adapter will then be created and visible in the Servers view.

Once the server is started, a new OpenShift connection should appear in the OpenShift Explorer view, allowing the user to quickly create a new Openshift application and begin developing their AwesomeApp in a highly replicatable environment.

Server tools

Wildfly 18 Server Adapter

A server adapter has been added to work with Wildfly 18. It adds support for Java EE 8 and Jakarta EE 8.

EAP 7.3 Beta Server Adapter

A server adapter has been added to work with EAP 7.3 Beta.

Hibernate Tools

Hibernate Runtime Provider Updates

A number of additions and updates have been performed on the available Hibernate runtime providers.

The Hibernate 5.4 runtime provider now incorporates Hibernate Core version 5.4.7.Final and Hibernate Tools version 5.4.7.Final.

The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.13.Final and Hibernate Tools version 5.3.13.Final.

Platform

Views, Dialogs and Toolbar

Quick Search

The new Quick Search dialog provides a convenient, simple and fast way to run a textual search across your workspace and jump to matches in your code. The dialog provides a quick overview showing matching lines of text at a glance. It updates as quickly as you can type and allows for quick navigation using only the keyboard. A typical workflow starts by pressing the keyboard shortcut Ctrl+Alt+Shift+L (or Cmd+Alt+Shift+L on Mac). Typing a few letters updates the search result as you type. Use Up-Down arrow keys to select a match, then hit Enter to open it in an editor.

Save editor when Project Explorer has focus

You can now save the active editor even when the Project Explorer has focus. In cases where an extension contributes Saveables to the Project Explorer, the extension is honored and the save action on the Project Explorer will save the provided saveable item instead of the active editor.

“Show In” context menu available for normal resources

The Show In context menu is now available for an element inside a resource project on the Project Explorer.

Show colors for additions and deletions in Compare viewer

In simple cases such as a two-way comparison or a three-way comparison with no merges and conflicts, the Compare viewer now shows different colors, depending on whether text has been added, removed, or modified. The default colors are green, red, and black, respectively.

The colors can be customized through usual theme customization approaches, including using related entries in the Colors and Fonts preference page.

Editor status line shows more selection details

The status line for Text Editors now shows the cursor position, and when the editor has something selected, it shows the number of characters in the selection as well. This also works in the block selection mode.

These two new additions to the status line can be disabled via the General > Editors > Text Editors preference page.

Shorter dialog text

Several dialog texts have been shortened. This allows you to capture important information faster.

Previously:

Now:

Close project via middle-click

In the Project Explorer, you can now close a project using middle-click.

Debug

Improved usability of Environment tab in Launch Configurations

In the Environment tab of the Launch Configuration dialog, you can now double-click on an environment variable name or value and start editing it directly from the table.

Right-clicking on the environment variable table now opens a context menu, allowing for quick addition, removal, copying, and pasting of environment variables.

Show Command Line for external program launch

The External Tools Configuration dialog for launching an external program now supports the Show Command Line button.

Preferences

Close editors automatically when reaching 99 open editors

The preference to close editors automatically is now enabled by default. It will be triggered when you have opened 99 files. If you continue to open editors, old editors will be closed to protect you from performance problems. You can modify this setting in the Preferences dialog via the General > Editors > Close editors automatically preference.

In-table color previews for Text Editor appearance color options

You can now see all the colors currently being used in Text Editors from the Appearance color options table, located in the Preferences > General > Editors > Text Editor page.

Automatic detection of UI freezes in the Eclipse SDK

The Eclipse SDK has been configured to show stack traces for UI freezes in the Error Log view by default for new workspaces. You can use this information to identify and report slow parts of the Eclipse IDE.

You can disable the monitoring or tweak its settings via the options in the General > UI Responsiveness Monitoring preference page as shown below.

Themes and Styling

Start automatically in dark theme based on OS theme

On Linux and Mac, Eclipse can now start automatically in dark theme when the OS theme is dark. This works by default, that is on a new workspace or when the user has not explicitly set or changed the theme in Eclipse.

Display of Help content respects OS theme

The post New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09 appeared first on Red Hat Developer.

In my previous article, I demonstrated the complete implementation for enabling OAuth-based authorization in NGINX with Keycloak, where NGINX acts as a relaying party for the authorization code grant. NGNIX can also act as a reverse proxy server for back-end applications (e.g., Tomcat, Open Liberty, WildFly, etc.), which can be hosted on an enterprise application server.

At times, back-end applications hosted behind NGINX are required to have role-based access control (RBAC), as RBAC helps to restrict resources based on users’ roles. In OAuth, roles associated with a user are available in the JSON Web Token (JWT), and thus one can capture the claim from the ID or access token, but the same should be shared through the header by NGINX:

ngx.req.set_header("X-USER", res.id_token.sub)
ngx.req.set_header("X-ROLE", res.id_token.role)

Here, I set the principal based on the subject claim, and the role based on the role claim available in the ID token. Usually, the role claim is not available in the ID token, but it is possible to add this information by configuring the mapper with the associated client in Keycloak.

Because I need to create the principal based on the username captured in the HTTP header, I extended HttpServletRequestWrapper to set the principal in the normal application flow:

public class ConfigPrincipal extends HttpServletRequestWrapper {
    String user;
    List<String> roles;
    HttpServletRequest realRequest;
    public ConfigPrincipal(String user, List<String> roles, HttpServletRequest request) {
      super(request);
      this.user = user;
      this.roles = roles;
      this.realRequest = request;
   }

   @Override
   public boolean isUserInRole(String role) {
    if (roles == null) {
      return this.realRequest.isUserInRole(role);
    }
    return roles.contains(role);
   }

   @Override
   public Principal getUserPrincipal() {
     if (this.user == null) {
       return realRequest.getUserPrincipal();
     }
     //make an anonymous implementation to just return our user
     return new Principal() {
     @Override
       public String getName() {
         return user;
       }
     };
   }

   public boolean authenticate(){
     return true;
   }
}

Next, I defined a servlet filter attached to the application so that it executes before the application’s business logic:

  @Override
  public void doFilter(ServletRequest req, ServletResponse response,
           FilterChain next) throws IOException, ServletException {
     
      HttpServletRequest request = (HttpServletRequest) req;
      String user = request.getHeader("X-USER");
      List<String> roles = new ArrayList<String>();

      //Capturing roles from the request header. 
      if (request.getHeader("role") != null) {
         String[] substrrole = request.getHeader("X-SSBRoleLevel").split(",");
         for (int i = 0; i < substrrole.length; i++) {
            roles.add(substrrole[i]);
         }
      }
      System.err.println("sidde roles:" + roles);
     //call the request wrapper , which overrides getUserPrincipal and is UserInRole
     next.doFilter(new ConfigPrincipal(user, roles, request), response);
   }

Now, request.getUserPrincipal() can be executed anywhere in the application to capture the principal, and request.isUserInRole(role) can be used to capture the associated role to have role-based access control.

The post Role-based access control behind a proxy in an OAuth access delegation appeared first on Red Hat Developer.