
Leading the Way: Payara Platform Community 7 Beta Now Fully Jakarta EE 11 Certified
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
Click here to see Part 2 (Access, Deploy & Test)
Today, one of the most important concerns for enterprise applications is to implement robust security mechanisms that allow developers and operation staff to easily integrate applications in a stable infrastructure and allow their users to interact with them in a seamless way. While many developers prefer to implement their own security mechanisms or use third-party libraries, a good alternative is to use already established products that handle authentication, authorization, confidentiality, identity, and entitlement on behalf of already developed applications.
The ForgeRock Identity Management Platform offers its customers a suite of tools that handle these concerns and allows an organization to configure their security infrastructure in a detailed way: directory services; identity management; personalized access to resources, services and devices and more. The ForgeRock suite has both commercial and open source support, allowing organizations to decide on the best model that suits them.
Currently, the ForgeRock suite of tools is composed of the following elements:
Source: official ForgeRock documentation
So how we Payara integrate with this suite of products? The most common scenario is to use OpenAM to function as an SSO gateway to all applications deployed in a Payara Server and allow it to handle identity administration and resource protection. This way, the administrators of OpenAM concerns themselves with managing users, roles and the access policies, without having developers code these access rules in their applications.
However, it must be taken into account that OpenAM is a Java Web application that can be deployed into any Java Web Container (Tomcat or Jetty for example) or an Enterprise application server (Wildfly, WebLogic, or in this case Payara Server). For a Payara Server domain to be connected with OpenAM, a special policy agent must be installed and configured in the Payara server domain. This agent will be responsible to delegate authentication to OpenAM and negotiate all policy authorization requests done in behalf of the applications and services deployed in the domain:
Click image to enlarge
However, there are 2 catches on this scenario:
Exception 0:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type UmaPolicyApplicationListener with qualifiers @Default at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.forgerock.openam.uma.rest.UmaIdRepoCreationListener(UmaPolicyApplicationListener)
at org.forgerock.openam.uma.rest.UmaIdRepoCreationListener.<init>(UmaIdRepoCreationListener.java:46)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type RequestHandler with qualifiers @Named at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.forgerock.openam.uma.rest.PolicyResourceDelegate(@Named RequestHandler)
at org.forgerock.openam.uma.rest.PolicyResourceDelegate.<init>(PolicyResourceDelegate.java:62)
Looking at this error, it seems there are some issues with the CDI bean discovery. We can try to disable Implicit CDI discovery at deployment time, but we still encounter more errors (related with Google Guice this time):
[2016-06-11T03:43:23.088+0000] [Payara 4.1] [SEVERE] [] [] [tid: _ThreadID=42 _ThreadName=admin-listener(4)] [timeMillis: 1465616603088] [levelValue: 1000] [[com.google.inject.CreationException: Guice creation errors:
1) No implementation for com.sun.identity.shared.debug.Debug annotated with @com.google.inject.name.Named(value=amThreadManager) was bound.
while locating com.sun.identity.shared.debug.Debug annotated with @com.google.inject.name.Named(value=amThreadManager)
for parameter 2 at org.forgerock.openam.shared.concurrency.ThreadMonitor.<init>(Unknown Source)
while locating org.forgerock.openam.shared.concurrency.ThreadMonitor
for parameter 1 at org.forgerock.openam.cts.reaper.CTSReaperInit.<init>(Unknown Source)
while locating org.forgerock.openam.cts.reaper.CTSReaperInit
for parameter 3 at org.forgerock.openam.cts.impl.CoreTokenAdapter.<init>(Unknown Source)
while locating org.forgerock.openam.cts.impl.CoreTokenAdapter
for parameter 0 at org.forgerock.openam.cts.CTSPersistentStoreImpl.<init>(Unknown Source)
at org.forgerock.openam.core.guice.CoreGuiceModule.configure(CoreGuiceModule.java:182)
2) No implementation for com.sun.identity.shared.debug.Debug annotated with @com.google.inject.name.Named(value=amThreadManager) was bound.
while locating com.sun.identity.shared.debug.Debug annotated with @com.google.inject.name.Named(value=amThreadManager)
for parameter 2 at org.forgerock.openam.shared.concurrency.ThreadMonitor.<init>(Unknown Source)
while locating org.forgerock.openam.shared.concurrency.ThreadMonitor
for parameter 2 at org.forgerock.openam.sm.datalayer.impl.SeriesTaskExecutor.<init>(Unknown Source)
at CTS_ASYNC
….
Regrettably, this means that we cannot use Payara Server to house OpenAM with the web applications we want to protect/secure.
2. There is not an official OpenAM Policy Agent compatible with Glassfish/Payara Server, meaning that there’s no way to handle policy negotiation between OpenAM and the applications deployed on the server.
What can be done in this case then? The OpenAM documentation recommends to use a separate Web Server to deploy the OpenAM application and use OpenIG in order to bridge OpenAM to incompatible application servers like in the case of Payara Server, so instead of using an OpenAM policy agent, an OpenIG route configuration is needed to delegate authentication and authorization to OpenAM when accessing protected applications.
click image to enlarge
With this in mind, we at Payara are not giving up at making Payara Server compatible with OpenAM and for this reason we are working on different mechanisms to make the application be deployed and executed without issues, so there is no need to use an additional web server for this specific arrangement.
We will update with the respective documentation in the future, so we appreciate your patience!
To illustrate the integration discussed earlier we will show the installation and configuration steps for a real world scenario of authentication and authorization:
OpenAM in particular needs to be configured using a data store for both its identity sources (users, roles, access rules, etc.) and its own configuration. For the scenario to be more practical we are going to use OpenDJ as a data store for both aspects and show the respective installation and configurations steps as well.
The following are the requirements needed in order to execute the installation and configuration of this scenario:
In order to install OpenDJ, we first must get the current distribution from the official website of ForgeRock. Take into account that community versions are the only releases that are available for the general public (otherwise a subscription to the commercial ForgeRock support services is required). For this installation process, we are going to download the ZIP distribution. Remember that to download the file you need to be subscribed to the ForgeRock community:
Unzip the file, and execute the bundled console installer:
unzip OpenDJ-3.0.0.zip
sudo mv opendj/ /opt/
sudo chown ec2-user:ec2-user -R /opt/opendj/
cd /opt/opendj/
./setup –cli
Once the setup installer starts, it will ask for the configuration settings used to create the domain configuration of the Directory Server:
Now, check the state of the server:
cd /opt/opendj/bin/
./status
(Take into account that executing commands using OpenDJ command-line tools will prompt for the credentials of a valid user – Directory Manager, in most cases). You should get information akin to this:
First, download the current open source available ZIP distribution of OpenAM from the ForgeRock website:
Unzip the file, and identify the WAR that will be used to deploy the application to the server:
Now, deploy the application to the Apache Tomcat Server:
cp ~/openam/OpenAM-13.0.0.war /opt/tomcat/webapps/openam.war
and access the application with the URL http://<host>:<port>/openam/:
With this, we can proceed to configure OpenAM. Since we want to use our OpenDJ installation as identity and configuration store, we click on the Create New Configuration link, accept the Software License agreement and complete the following steps:
First, download the current WAR distribution of OpenIG from the ForgeRock website:
Now, deploy the application to the Apache Tomcat Server:
cp ~/openig-war-4.0.0.war /opt/tomcat/webapps/ROOT.war
It is important that you deploy this application in the ROOT context of the web container that you are using (in this case Tomcat). Since this step overrides the Tomcat default root context application (the Tomcat welcome page), you might consider using a separate web container for hosting OpenIG separate of OpenAM in a production environment.
Now, access the application in the root context to check it has been installed correctly (again, by accessing Tomcat in the ROOT context):
Share:
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
Enterprise Java applications power global commerce, healthcare, government and countless other industries. These systems must be scalable, secure and […]
You’ve probably been in that hallway conversation (or Teams/Zoom meeting) where DevOps, SRE and Platform Engineering all get thrown around. Sometimes these words are […]
Awesome!
Any updates on this in release 5.192? Also, can we use web agents instead of OpenIG?