Profiling Heap Stats of Java Applications - Java Flight Recorder(JFR)

Java Flight Recorder (JFR) is a tool for collecting diagnostic and profiling data about a running Java application. In this post, I am going to explain how create detailed profile including heap and class statistics of your java application. As you may already know, JFR will be executed via JCMD Utility which sends diagnostic command requests to the JVM.

jcmd.exe comes by default with JDK installation which you can find in $JAVA_HOME\bin directory. What JFR does is collecting low level and detailed run time information of java applications that runs on top of JVM. JFR comes with a default profiler which has generic recording templates that you can find in below directory of the JDK installation.

$JAVA_HOME\jre\lib\jfr

Using below in command prompt, you can collect general profiling information which used default setting.

jcmd.exe ProcessID JFR.start duration=600s filename=FileName.jfr

Above command will use "default.jfc" which is written to collect below run-time statistics.

Now let's see how to conduct a detailed profiling by changing these settings. To do this, open the recording that first collected using default settings. This will open up "Oracle java Mission Control" UI. Now select "Window -> Flight Recording Template Manager" from the menu.

Select "Default" and then click "Duplicate". Then select newly created template and click "Edit". You can then make changes highlighted in below image and click OK. This will add a new template "DetailedProfiling" which we can now use for detailed profiling.

Now open the command prompt and execute below command.

jcmd.exe ProcessID JFR.start settings=C:\Java\jdk1.7.0_80\jre\lib\jfr\DetailedProfiling.jfc duration=600s filename=FileName.jfr

This will now start the recording and once the profiling duration is completed, you can open it and see statistics related to Memory, Code, System, etc which will really be useful in finding memory leakages and performance improvements of java applications.

Single Sign On - SAML

In this article, I am going to explain how to enable Single Sign On(SSO) capability of a java application using SAML 2.0. To implement SSO, I recommend to use the SAML toolkit provided by Onelogin SSO

They provide open source library toolkit for many languages, tools to decode/encode certificates, keys and most importantly, they offer an IDP server account which we can configure and can use to test out service provider application. Following is a screenshot of IDP configuration provided by Onelogin.

First of all, download the SAML toolkit for Java hosted in Github. This is a Maven project, so that, you can customize dependencies and test cases as you needed. Open the toolkit in whatever the IDE you have and build the project.

PS: you can disable building test cases of this project by adding following block to the pom.xml.

                       

Next, we need to modify the metadata of the Service Provider(SP) and Identity Provider(IDP). All these information can be configured in the property file located at "java-saml-tookit-jspsample\src\main\resources\onelogin.saml.properties". Following are the basic properties that you are needed to modify;

Identifier of the SP entity  (must be a URI)

onelogin.saml2.sp.entityid

Service Provider return URL. Specifies info about where and how the message MUST be returned to the requester.
onelogin.saml2.sp.assertion_consumer_service.url
                         
Identifier of the IdP entity  (must be a URI)
onelogin.saml2.idp.entityid

SAML 2.0 Endpoint (HTTP)/ SSO endpoint info of the IdP. (Authentication Request protocol)
URL Target of the IdP where the SP will send the Authentication Request Message
onelogin.saml2.idp.single_sign_on_service.url

Public x509 certificate of the IdP
Put your IDP's certificate details here. You can either provide certificate or fingerprint with algorithm
onelogin.saml2.idp.x509cert

If a fingerprint is provided, then the certFingerprintAlgorithm is required in order to let the toolkit know which Algorithm was used. Possible values: sha1, sha256, sha384 or sha512
This can be easily customized in the IDP provided by onelogin
onelogin.saml2.idp.certfingerprint
onelogin.saml2.idp.certfingerprint_algorithm

Above few properties are the all you need to run the basic set up. As your requirement, you can set other attributes like signing, validation, etc.

Note: If you are using Mozilla Firefox as teh browser, there is a addon called "SAML Tracer" in which facilitates you to trace SAML request/response messages.

• If I describe what is actually happening here;First, when user comes to the login page, it automatically redirect the HTTPRequest to IDp. This us called "Authentication Request". For more details about the, SAML request have a look on below screenshot.

• Then, the request reaches the IDP and checks for available user session corresponding to received HTTPRequest. If there is an active session for the particular user, then this data will be sent back to SP as a SAML response. Otherwise, IDP will urge teh user to login first and captures the user data  which will be then sent to SP.
  

•  Service provider receives SAML Response and authenticates the message. In doing so, SP will use either IDP certificate or fingerprint configured in the metadata. To do this, SP will use several tags in SAMLResponse like  ds:SignatureValue, ds:X509Certificate, ds:DigestVauue

Now, all are customized in the sample project. After building sample application "OneLogin java-saml Toolkit Samples", you can place the .war file in whatever the server environment installed in your machine.