Monday, December 23, 2013

Accessing Credential Store from ADF application

Sometimes we need to use credentials (username and password) in ADF applications to connect to backend applications.

We had a scenario where we needed to add attachments to the Imaging server using imaging webservice from an adf form. To access this particular service, we needed to use credentials of the Admin user, in our case it was 'weblogic'.

Considering these credentials can be different per environment, you would be tempted to put it in a properties file or in a database table. This is a big security risk considering the passwords can be in plain text format. You can apply encryption and decryption mechanism to store the password in encrypted format, but that requires additional development time and still not fool proof.

Oracle Platform Security Services includes the Credential Store Framework (CSF), a set of APIs that applications can use to create, read, update, and manage credentials securely OPSS is inherent part of Fusion Middleware Security and can be used within applications running on fusion middleware platform.
The Credential store basically comprises of maps with unique names and each map can store or retrieve credentials based on a unique Key, for which we need to create a credential store entry for the Key, update the jazn-data.xml file of your ADF application to allow credential store to be accessed by the application and finally write a java code to access the credential store.

Below are the steps you need to follow to access the credential store from ADF application:
  1. Adding a key "basic.credential" to an already existing map ""
  2. Log  into Enterprise Manager and select your weblogic domain , from the drop down select securities and then click on Credentials

  3. Select the map(in our case we are using an already existing  map “”) where you want to add the key and click on Create Key

  4. Following window opens , where you can fill the details and click OK

  5. Your key is now created and map is updated

  6. Open you adf project and update its jazn-data.xml to add following credential access permission to use newly created key in credential store 


    Above mentioned policy enables access to the credential store for the application containing the java class implementing the credential store access.
    Where CodeFormApp_V2.0  is the name of our ADF application.

    The name of your application is the name of your EAR and appended with _V2.0 if ADF Security is enabled. You can also validate the path of your deployed application from the value of url in the codesource element of the jazn policy mentioned above. 

  7. Now add the following code to your java class to retrieve the user credentials

    public  String[] getUserCredentials() {
            String[] password = new String[2];
            try {
                JpsContextFactory factory = JpsContextFactory.getContextFactory();
                JpsContext jpsContext = factory.getContext();
                final CredentialStore store =
                Credential cred =
                    AccessController.doPrivileged(new PrivilegedExceptionAction<PasswordCredential>() {
                        public PasswordCredential run() throws JpsException {
                            return (PasswordCredential)store.getCredential("",
                PasswordCredential pwdCred = (PasswordCredential)cred;
                password[0] = pwdCred.getName();
                password[1] = new String(pwdCred.getPassword());
            } catch (PrivilegedActionException exc) {
                              "Error getting credentials from default store:" +
                              exc.getMessage() + "\nStackstrace: " + exc.getStackTrace());

            return password;

    Where password[0] is the value of username and password[1] is the value of password.

    Above values can be used to access the webservice.

I hope that this code tip helps you out!

Thanks to Siddhartha Agarwal for today's article.


Wednesday, December 18, 2013

Keep Current! - WebCenter Patches as of 2013/12/18

Hey all, 

In an effort to help everyone stay current, we're going to post some preferred patches on a regular schedule. This way, you'll have a single place to find all of the updated cumulative patches (MLRs, ARUs, Bundle Patches, etc) for the month.

Please be sure to let me know if there's any other patches that should be included on this list. The current format has the support recommended installs in bold & underlined, but there are some other nice-to-know patches included as well. These nice-to-know patches may not be necessary for your particular installation.

The formatting may change over time, but hopefully this is helpful!

** As always, please be sure to do your own due diligence before applying any patch. This list is for reference only.

Oracle Patches[1]

·       14538406 – 2012/09/17 – ODC Patch 4 for (cumulative)
·       16312671 - 2013/02/15 – CPUAPR2013 Oracle Document Capture (ActiveX IE killbit to prevent certain ActiveX controls; verify before installing!)
WEC (Capture 11g)
·       17550433 – 2013/11/15 – Cumulative Capture Patch #2
·       13882540 – 2012/04 – Critical Patch Update
·       13548500 – 2011/12/30 – Registry fix for searching for vendors with identical addresses
·       11813845 – 2011/02 - OFR Patch 1 (not cumulative)
·       12692984 – 2011/06 – OFR Patch 2 (not cumulative)
·       12372094 – 2011/04/27 – (updated ODC macros)

WebCenter Content Patches

o    17453460 – 2013/09/30 – MLR02
o    17768935 - 2013/11/15 – OIT cumulative patch
o    17525726 – 2013/11/05 - MLR03
o    17768935 - 2013/11/15 – OIT cumulative patch
o    17596120 – 2013/11/22 – MLR17
o    17768935 - 2013/11/15 – OIT cumulative patch

WebCenter Content Imaging Patches
o    17934512 – 2013/12/13 - CUMULATIVE IPM/AXF PATCH NUMBER 7
o    17056936 – 2013/07/21 - CUMULATIVE EBS PATCH NUMBER 1
o    16403418 – 2013/03/12 - CUMULATIVE FUSION APPS PATCH NUMBER 1
o    17565125 – 2013/10/06 - CUMULATIVE IPMREPOSITORY PATCH NUMBER 1
o    17831350 – 2013/11/22 - CUMULATIVE IPM/AXF PATCH NUMBER 22
o    17057174 – 2013/07/05 - CUMULATIVE EBS PATCH NUMBER 5
o    16547732 – 2013/03/29 - CUMULATIVE FUSION APPS PATCH NUMBER 4
BAM Patches
·       (No cumulative patch threads could be found, but many one-off patches exist)

·       (ten new one-off patches since last month)
·       14491485
o    Bug #14491485

SOA Manager Patches
·       (Note that there are many one-off patches available)

o    17014142 – 2013/11/15 – Bundle Patch

o    16702086 – 2013/11/05 – Bundle Patch

** Note that there are multiple “merge request” patches per SOA release; they do not appear to be cumulative; please research and download as applicable for your version
WLS Patches
·       10.3.6
o    17071663 – BYJ1 - 2013/10/15 – WLS Patch Set Update
* Note that WLS has many one-off patches and “merge request” patches; please research and download as applicable for your version
WebCenter Portal

o    17299932 – 2013/10/17 – WebCenter Portal Bundle Patch

o    16761779 – 2013/07/23 – WebCenter Portal Bundle Patch
o    16269470 – 2013/07/23 – WebCenter Portal Bundle Patch
o    14823234 – 2013/07/23 – WebCenter Portal Bundle Patch

o    17328920 – 2013/09/25 – Content Presenter throws stuck thread and OOM when UCM returns many profiles

** Note that there are many one-off and “merge request” patches per Portal release; they do not appear to be cumulative; please research and download as applicable for your version

[1] *requires a valid support agreement to download patches

Tuesday, December 17, 2013

Tip of the Day: AccessControlException - userTimezone

While opening the a java applet, you face below exception

The java.policy file present in the java installed directory to which Java TM plugin is pointing is not having permission to write user.timezone value.
1.       Locate the java.policy file of Java TM browser plugin
1.1.    The link “” says about how to find java version, however I am still looking for the exact way to locate java.policy file which is being referred by Java TM browser plugin.
1.2.    This file is present in java installed directory, e.g. C:\Program Files (x86)\Java\jre7\lib\security
1.3.    If you are not sure about the location then I will suggest you to add grant in all the java.policy files present in your computer in all the drives.
2.       Add below entry in “grant {….}”, this is the last grant snippet in the file.
2.1.    permission java.util.PropertyPermission "user.timezone", "write";

I am not going into the details of security implications of this setting, so please do your own due diligence on whether this quick fix will suffice in your own situation. 

Thanks to Vikrant Korde for today's Tip!