Wednesday, July 18, 2018

Enable TLS 1.1 & TLS 1.2 in Java JDK

Starting from Java JDK 1.8. XX versions TLS 1.1 & TLS 1.2 is enabled by default.

But, what if you are in JDK 1.7. XX versions you will have to go enable them explicitly.

How you do it? One way is that you can enable from Java Control panel console.


Navigate to JAVA_HOME\jre\bin folder and execute javacpl.exe from command prompt.


 Navigate to JAVA_HOME\jre\bin folder and execute ./ControlPanel from terminal.

This will render Java control panel console. Click on Advanced tab and scroll down where you see Advanced Security settings section.

Select the check boxes associated with "Use TLS 1.1" & "Use TLS 1.2" then click Apply and OK.

Siva Pokuri.

Friday, June 29, 2018

Weblogic Stuck threads

One way to check if you have stuck threads is through Weblogic Admin console.

  1. Login to weblogic admin console with admin credentials.
  2. Expand Environment and click on Servers in the left menu
  3. Click on the Admin server or any managed server you want to check the stuck threads
  4. Click on the Monitoring tab in the server properties
  5. click on Threads tab.
  6. Check the Health column in Self-Tuning Thread Pool table. If it says OK there are no stuck threads.
  7. If Health column value shows "Warning" there are stuck threads in JVM.
  8. Next thing is that you will have to find the root cause of the stuck threads. For that JVM thread dump needs to be taken.
  9. There is a tool called jstack starting from JDK 1.6 version.
  10. Find out the process ID of the weblogic service and execute "jstack <<PID>> > threaddump.log"command.
  11. Above command generates threaddump.log file with JVM thread dump.
  12. Check the STUCK threads and fix the issue. It might be in application code or connection to external services.
Happy debugging.

Siva Pokuri.

Wednesday, June 13, 2018

List Of Oracle Identity Manager 12C Connector

                                  Oracle Identity Manager 12C Connector Downloads

Here is below link where you can download Oracle Identity Manager 12C Connectors

Below are list of Oracle Identity Manager 12C Connectors  


Sunday, June 10, 2018

Single Sign-On recommendations

It's increasingly challenging to manage multiple identities of an individual and it's operational overhead to the organizations.
Implementing the Single sign-on solution in an organization to authenticate and SSO'ing for applications access within an enterprise will reduce operational overhead and cost to the organization.
Traditionally, there is header based Single Sign-On as it's still out there lingering in the market. In Early 2000's, it's noted that SAML is widely accepted mechanism for SSO requirements. Later in the game, late 2000's where mobile applications and API based designs came into the picture there comes OAuth authorization mechanism.
The goal of each SSO mechanism is very simple "One login to multiple applications". Well, definitely it's not that easy to enable SSO as stated.
When it comes to the recommendation on Single Sign-On to an enterprise application, I would suggest considering below list of choices and take the wise decision to implementing Single Sign-On.
Option 1: Legacy application with no delegated authentication capability to external authentication engine with Header based authentication. Note that this approach needs code change in the application authentication mechanism.
Option 2: Application that's fitted of delegating authentication to SAML Identity provider (IDP) then just go with it without further thought.
Option 3: Planning for developing a new application and studying about the authentication mechanisms in architecture then consider Open ID / OAuth (3 legged )as a primary option.
It's recommended to read and understand each Single Sign-On mechanism before going to the implementation phase.
Happy SSO'ing.

Friday, May 25, 2018

Header Based application SSO integration with Azure AD + Ping Access

Header Based application SSO integration with Azure AD

  • Azure AD with premium subscription
  • Ping Access
  • Azure AD Application connector

Configure Azure Application proxy

1.       Login to with global admin credentials
2.       Download Application proxy connector from Azure
3.       Install Application proxy in on-premise Windows Server 2012 R2 or 2016

Configure Azure AD for application

1.       Navigate to Azure AD Connect and then Enterprise applications
2.       Click on New Application
3.       Select On-premises application from the options
4.       Fill the application form
a.       Name: <<Application Name>>
b.       Internal Url: <<Normally you provide the URL that takes you to the app’s sign in page when you’re on the corporate network. For this scenario the connector needs to treat the PingAccess proxy as the front page of the app. Use this format: https://<host name of your PA server>:<port>. The port is 3000 by default, but you can configure it in PingAccess.>>
c.       External URL: <<Will be built automatically>>
d.       Pre- Authentication: <<Leave default>>
e.       Connector Group: <<leave default>>
f.        Backend application Timeout: <<leave default>>
g.       Headers: No
h.       Application Body: no
5.       Click on Add
6.       Select Assign user for testing in quick start menu of the application and add a user to application
7.       Click on App management and select Single sign-on
8.       Select Header-based sign-on from the drop down and click on Save
9.       Click on App registration and select the All Apps from the drop down
10.   Click on the application you just created
11.   Click on settings button on the top
12.   Click on Reply URLs
13.   Check and confirm if the application External URL it was built in Step 7. If not present add it.
14.    Click on Required permissions section
15.   Select Add, For the API, choose Windows Azure Active Directory, then Select. For the permissions, choose Read and write all applications and Sign in and read user profile, then Select and Done.
16.   Grant permissions before you close the permissions screen.
17.   Click on the Properties section and save Application ID value. This is used for the client ID when you configure PingAccess.
18.   On the app settings blade, select Keys.
19.   Create a key by entering a key description and choosing an expiration date from the drop-down menu.
20.   Select Save. A GUID appears in the Value field. Save this value now, as you won’t be able to see it again after you close this window.
21.   Close the App registrations blade or scroll all the way to the left to return to the Azure Active Directory menu.
22.   Select Properties.
23.   Save the Directory ID GUID.

Ping Access Configuration as a token provider

1.       Navigate to Settings → System → Token Provider.
2.       In the Issuer field, enter the Microsoft Azure AD Directory ID. To obtain the Directory ID from Azure AD, in the Azure AD directory, navigate to Manage → Properties and copy the Directory ID value.
3.       Provide a Description of the token provider.
4.       In the Trusted Certificate Group list, select Java Trust Store or Trust Any.
5.       Click Save.
Ping Access Configuration for application
Note: Assuming you have installed Ping Access and can access the Administrative console.
1.       Creating virtual host
a.       Navigate to Settings → Access → Virtual Hosts.
b.       Click Add Virtual Host.
c.       In the Host field, enter the FQDN portion of the Azure AD External URL. For example, external URLs of and will both demand a Host entry of
d.       In the Port field, enter 443.
e.       Click Save.
2.       Creating web session
a.       Navigate to Settings → Access → Web Sessions.
b.       Click Add Web Session.
c.       Provide a Name for the web session.
d.       Select the Cookie Type, either Signed JWT or Encrypted JWT.
e.       Provide a unique value for the Audience.
f.        In the Client ID field, enter the Azure AD Application ID.
g.       In the Client Secret field, enter the Key you generated for the application in Azure AD.
h.       Click Save.
3.       Create identity mapping
a.       Navigate to Settings → Access → Identity Mappings.
b.       Click Add Identity Mapping.
c.       Specify a Name.
d.       Select the identity mapping Type of Header Identity Mapping.
e.       In the Attribute Mapping table, specify the required mappings. Example: family_name, given_name
f.        Click Save.

4.       Create a site
a.       Navigate to Main → Sites → Sites.
b.       Click Add Site.
c.       Specify a Name for the site.
d.       Enter the site Target. The target is the hostname:port pair for the server hosting the application. Do not enter the path for the application in this field. For example, an application at https://mysite:9999/AppName will have a target value of mysite:9999
e.       Indicate whether or not the target is expecting Secure connections.
f.        If the target is expecting secure connections, set the Trusted Certificate Group to Trust Any.
g.       Click Save.
5.       Create an application
a.       Navigate to Main → Applications.
b.       Click Add Application.
c.       Specify a Name for the application.
d.       Optionally, enter a Description for the application.
e.       Specify the Context Root for the application. For example, an application athttps://mysite:9999/AppName will have a context root of /AppName. If the application is on the root of the server, you can set the context root as /. The context root must begin with a slash (/), must not end with a slash (/), and can be more than one layer deep, for example,/Apps/MyApp.
f.        Select the Virtual Host you created.
g.       Select the Web Session you created.
h.       Select the Site you created that contains the application.
i.         Select the Identity Mapping you created.
j.         Select Enabled to enable the site when you save.
k.       Click Save.
Now, access your application URL using external URL generated in Azure AD portal for your application.