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:

4 comments:

  1. nice posting i think. thanks.
    but, i have a problem,
    my wls realm ("myrealm") has one more provider and it's sql auth. it's work fine and i get user, group, and it's maping in WLS realm.
    when i use it in my app it's just looking at user and group from defaultAuth and not from my sql auth.
    any time i use user account from sql auth provider, my adf app can't read the role, although it's login success.
    the adf app just looking at approle that happen in the authrole subrole. once i insert any app-role in authrole subrole, the role become admin.

    after hour looking at internet, some people say that i must migrating the policies. looking and still looking, i found this blog, but when i insert application-param, it said that application param not expected.

    where i should insert this param ? i insert it in my weblogic-application.xml and it said error.

    or you have anothe way around for troubleshooting my problem ?

    anything would be so great.
    anyway i'm using jdev 11g R1 and oracle enterprise 10g

    thanks a lot,
    Yoel

    ReplyDelete
  2. Thanx!

    It can login but cannot see role! Strange!
    Some things that might help though:

    1.
    Check SUFFICIENT and the order of Ath providers.
    In this http://adfhowto.blogspot.com/2011/07/setting-up-ms-active-directory-as.html post I set this settings for Active Dirctory. Do the same in your case.

    2.
    Go to Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework
    11g Release 1

    Check section 30.8.2 What Happens When You Configure Security Deployment Options (section number may vary depending on version). Here you find setting regarding weblogic-application.xml

    Beware of the note:
    Note: When you eventually deploy to a production environment, the
    migration settings in the weblogic-application.xml file are
    ignored;


    3.
    Check what kind of domain you have development or production
    (http://adfhowto.blogspot.com/2011/02/check-if-your-weblogic-domain-is-in.html)
    In case that is produciton, check 30.9 Preparing the Secure Application for Deployment of same guide.

    Hope it helps.

    ReplyDelete
  3. first thank's that now i know more about WLS and how it's security works.

    but, i tried all off thing you have said and still got the same prob.

    it's not that wls doesn't read role at all.
    login using jdev created user or wls created user that provided by defaultAuth, it's work normal... and, it's read role that added at root level at jdeveloper. when i use sql auth provider user, in my case from data base and already works fine in WLS, it's return all role from sqlAuth provider as authenticated-role in jdeveloper. so, when i login using user that has marketing role, it's read as authenticated-role in my ADF app, although i get marketing role in root level of jdev security, it's keep return that user as autheticated role.

    thanks before for you attention.
    best regard,

    Yoel

    ReplyDelete
  4. Yoel,
    Your are always welcome! Unfortunately I am on vacations now and with very pour mobile internet reception area.

    I 'll try to come back to you when I ll be back to civilization :)

    ReplyDelete

You might also like:

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