26 July 2011

OPSS config files: jps-config.xml, jazn-data.xml and cwallet.sso

Reposting a very helpful post OPSS Artifacts Life Cycle in ADF applications of Andre Correa.

After writing about users and groups migration, it looked to me we should also talk about the life cycle of other important entities in secured ADF applications. When you enable security in an ADF application, you see a couple of new artifacts in your JDeveloper workspace, namely jps-config.xml, jazn-data.xml and cwallet.sso.
Have you ever wondered what their purpose is, their life cycle and how they relate to WLS domain security configuration? This article is just about it.
As you might know, secured ADF applications leverage OPSS (Oracle Platform Security Services).
OPSS is a fundamental component within Oracle Fusion Middleware security. It works as an abstraction layer on top of security services providers, shielding applications from all the complexities in dealing with them. For instance, applications can transparently switch between file-based and LDAP-based policy stores. Likewise for credential store services.
Let's take a closer look at each of those artifacts and their life cycles.

jps-config.xml

This file can be seen as the lookup services registry for OPSS. Among these services are login modules, authentication providers, authorization policy providers, credential stores and auditing services.
Whenever an OPSS-enabled application requires security services, it looks up a JPSContext object where all the necessary services are supposedly configured.
In ADF applications, a workspace-level jps-config.xml is created once ADF security is enabled. It drives services lookup for ADF's BC (Business Components) Tester available in JDeveloper, which is a JavaSE application.
If you want to have security unit tests, you can also easily leverage it.
It is never used once the ADF application gets deployed in a WLS container, even though it is packaged in the ear file. Within a WLS container, a jps-config.xml in /config/fmwconfig is used by all applications in all servers deployed in that WLS domain. There's no such concept of an application-level or server-level jps-config.xml.

jazn-data.xml

This file keeps users, groups and authorization policies for OPSS-enabled applications and is automatically created once ADF security is enabled. I've already covered users and groups life cycles in a previous article. It is important to mention that users and groups are also leveraged by ADF's BC Tester and can be integrated into security unit tests as well.
Authorization policies are, if not the most, one of the most sensitive parts of a secured ADF application, since it governs who has access to what. As you might guess, they are also leveraged by ADF's BC Tester. When the ADF application is deployed into WLS, at startup time, policies are OOTB (Out-Of-The-Box) migrated into the configured policy store, who, by default, is a file called system-jazn-data.xml, located under /config/fmwconfig. You can configure how (and if) policies are migrated through some properties in weblogic-application.xml. Here they are:
<listener>
 <listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener<listener-class>
<listener>
This listener is the one actually responsible for pushing the changes to the runtime policy store. Make sure it is present in weblogic-application.xml. Otherwise, you’ll experience a lot of frustration in trying to deploy authorization policies along with your application.
<application-param>
    <param-name>jps.policystore.migrationparam-name>
    <param-value>[MERGE|OVERWRITE|OFF]param-value>
application-param>
MERGE, OVERWRITE and OFF are exclusive and applicable for deployments and redeployments. And they mean exactly what you might be thinking.
  • MERGE will merge what’s already available in the runtime policy store. This might be particularly useful in some advanced deployments where more than one application share the same application policy stripe.
  • OVERWRITE wipes away the existing application policy stripe and load all policies from scratch.
  • OFF skips policy migration.
Do notice that once the application is undeployed, its policies are also removed from the policy store, unless you set the following property in weblogic-application.xml:
<application-param>
    <param-name>jps.policystore.removalparam-name>
    <param-value>OFFparam-value>
application-param>
Authorization policies migration will always happen according to weblogic-application.xml configuration, no matter what the deployment method is.

cwallet.sso

This file keeps credentials used by the application. A subtle and fundamental distinction is important to be made here: credentials and identities are not the same thing. Simply put, in OPSS, identities are what authentication requests are done against, while credentials are securely kept objects that are somehow presented to authentication providers to be matched against identities.
cwallet.sso is encrypted and you cannot browse it or explicitly edit it via JDeveloper. At design-time, different components make use of cwallet.sso and are responsible for creating the necessary credentials in it. Examples are OWSM policy attachments that override the csf-key and ADF connections requiring credentials in the call out.
If you need credentials that can’t be created within JDeveloper, you can either use wlst createCred online command or write some code using OPSS APIs. Both options makes the whole life cycle story a little catchy, because a running WLS container is necessary. You can also disable credentials migration and create them directly in the WLS domain where applications are deployed.
Like authorization policies, credentials are also OOTB migrated into the configured WLS domain credential store on application startup. By default, the credential store is the cwallet.sso file in /config/fmwconfig folder.
The following weblogic-application.xml properties govern how (and if) they're deployed.
<listener>
  <listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListenerlistener-class>
listener>
As for policies, the same listener migrates credentials. Avoid frustration and make sure the listener is present if you want to migrate or control how your credentials are migrated.
<application-param>
    <param-name>jps.credstore.migrationparam-name>
    <param-value>[MERGE|OVERWRITE|OFF]param-value>
application-param>
  • MERGE: migrate non-existing credentials only;
  • OVERWRITE: overwrites existing credentials;
  • OFF: skips credentials migration; 



Dig more:
Do not forget to check also another 2 very good posts of the Andre:

25 July 2011

A Case Study in an Oracle Forms Redevelopment Project to Oracle ADF

A very useful  white paper  by Grant Ronald about redeveloping Forms to ADF. Quoting him "This paper covers topics such as design decisions, architecture, best practice, coding standards we well as showing common mappings of Oracle Forms features to Oracle ADF."

More on his blog post.

21 July 2011

How to configure the Active Directory Provider Specific settings in your Weblogic

In a previous article Setting up MS Active Directory as Authenticator Provider in Weblogic, it is described how to set Active Directory Provider.
Now we ll see how to see the Provider Specific settings based on your Actice Directory structure that was not mentioned then.

Open the Active Directory Provider that you want to configure its Specific setting 


On Host and Port provide the related ones.

Open Active Directory Users and Computers from the Administrative Tools


In the WLS's Provider Specific settings, set the Principal field based on the Username, User folder and domain name.
e.g.
As we can see from above the Principal would be:

cn=weblogic,cn=Users,dc=YourDomain,dc=com

As you can notice dc=com is because the .com in the domain name.

In the Credential type the one provided by your Administrator.

In the WLS's Provider Specific settings, set the User Base DN:
ou=Users,ou="Your Organizational Unit",dc=YourDomain,dc=com
based on the following:


 Set the Group Base DN:
ou="Your Organizational Unit", dc=YourDomain,dc=com
based on the following:

Note: use "" when you name contains spaces.


The value of the fields that you depend on the structure of your AD and might vary in your case.


TROUBLESHOOTING: The domain edit lock is owned by another session in non-exclusive mode (WLS deployer)

Error
[Deployer:149163]The domain edit lock is owned by another session in non-exclusive mode - this deployment operation requires exclusive access to the edit lock and hence cannot proceed. If you are using "Automatically Aquire Lock and Activate Changes" in the console, then the lock will expire shortly so retry this operation.

Solution
Actually what Deployer is trying to tell you is that it tried to deployed but another user has Lock and Edit the domain . More regarding Lock and Edit in this related post.

In other not to fail but exist gracefully leaving you deployment to be applied when the Lock is released, then use nonexclusivelock option.

Using this option you ll get the following message, if another user has avquire the lock and the script will not fail:
[wldeploy] Operation is pending and will be activated or cancelled when the ongoing edit session is activated or cancelled.


In case if you use a wldeploy ant task, here is an example script

<project name="deploy" default="deploy">
<property file="deploy.properties" />

<!-- Setting TaskDefinition -->
<taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.WLDeploy">
    <classpath>
        <pathelement location="${wldeploy.home}/weblogic.jar"/>
    </classpath>
</taskdef>
<!-- Deploying Applications  -->
<target name="deploy">
<wldeploy action="deploy"
          name="${deploy.name}"
          source="${deploy.source.path}/${deploy.source.ear}"
          verbose="true"
          adminurl="${connection.protocol}://${wls.hostname}:${wls.port}" 
          targets="${deploy.target}"
          upload="true"
          user="${wls.username}"
          password="${wls.password}"
          usenonexclusivelock="true" />
</target>
</project> 
 
 
 
Dig more:

20 July 2011

TROUBLESHOOTING: Bad Request' for url: '.../bea_wls_deployment_internal/DeploymentService (upon WLS deployment)

Error
weblogic.deploy.api.internal.utils.DeployerHelperException: The source '/tmp/ApplicationGreeceDEV.ear' for the application 'ApplicationGreeceDEV#2.0'
could not be loaded to the server 'http://127.0.0.1:7007/bea_wls_deployment_internal/DeploymentService'.
Response: '400: Bad Request' for url: 'http://127.0.0.1:7007/bea_wls_deployment_internal/DeploymentService'

Solution
I know it seems silly but do not waste time. Just restart server.

TROUBLESHOOTING: Changing the source location is not allowed for a previously attempted deployment. Try deploying without specifying the source. (WLS Error upon deployment)

Error
[Deployer:149007]New source location, '/u01/app/oracle/product/Middleware_1034/user_projects/domains/dev/servers/AdminServer/upload/ApplicationGreeceDEV/2.0/app/ApplicationGreeceDEV.ear',
 cannot be deployed to configured application, 'ApplicationGreeceDEV [Version=2.0]'. 
The application source is at
 '/u01/app/oracle/product/Middleware_1034/user_projects/domains/dev/servers/AdminServer/upload/ApplicationGreeceDEV.ear'.
 Changing the source location is not allowed for a previously attempted deployment. Try deploying without specifying the source.

Possible solution
(or  Solution that worked in my case)

-Undeploy the application.

-Go to Admin server's upload folder

eg. upload in my case

cd /u01/app/oracle/product/Middleware_1034/user_projects/domains/dev/servers/AdminServer/upload

-Remove any relate archives or directories
eg. ApplicationGreeceDEV.ear or ApplicationGreeceDEV directory
from upload folder


17 July 2011

How to set the client and server VM option in JDeveloper

How to set it
Right click you project
Go to Run/Debug/Profile
Edit
Select the option you prefer from the Virtual Machine drop down list.


Now when you run you application you ll see the switch in the java run.


Strange behavior
When running the BC tester or a typical java app it seems to take the setting. When running ViewController it ignores it. Strange...


What is client and server VM  options
Regarding the  the client and server VM options you can check my other post - Difference between -client and -server JVM command line options.
In 2 words: The client system is optimal for applications which need fast startup times or small footprints, the server system is optimal for applications where the overall performance is most important. In general the client system is better suited for interactive applications such as GUIs. Some of the other differences include the compilation policy,heap defaults, and inlining policy.

JRockit  client and server VM  options
Make sure when you run your Fusion applications over JRockit not to have the -client option in your java run.
Check my other post - Difference between -client and -server JVM command line options  for more.

Dig more:

12 July 2011

How to change Weblogic server's log file path

i.e. where WLS saves its log file.

Under Domain Structure
Go to Environment and
then Servers.
Click on the Server you want to change the log (that is DefaultServer(admin) in case of integrated WLS)
Click Logging tab

Set Log file name with desired path and name.


 You can tune other params there too.

06 July 2011

Setting up MS Active Directory as Authenticator Provider in Weblogic

How to do it
Got to:
Security Realms
My realm
Providers
Click: New
Enter:
     Name eg. ADProvider,
     Type: ActiveDirectoryAuthenticator



OK

All the Providers will be displayed.
Click Reorder
Set the new Provider to be on top
 

 Open again the newly created Provider

Enter: Control Flag: SUFFICIENT


Click Provider Specific and enter all the Active Directory related settings.
Check here for a how to.

Usually, depending on the priority that you want the providers to have, you may want to change the Control Flag from REQUIRED to SUFFICIENT in the DefaultAuthenticator of WLS, too.

To check if it works:
Restart Weblogic
Go to
Security Realms
My realm
Users and Groups
There you must be able to see the users and groups of your Active Directory.


Src/Dig more:

You might also like:

Related Posts Plugin for WordPress, Blogger...
There was an error in this gadget