Problems with hosts file and "TNS:could not resolve the connect identifier specified"

If you update your hosts file as I described in a recent post to disassociate 127.0.0.1 with your host name you may get an error when you try to spin up anything using the database "TNS:could not resolve the connect identifier specified".

This is not technically a middleware problem - it's a problem with the database. But if you're like me you're probably not a database expert and won't know how to fix it.

So here's how to fix it...

OPSS Artifacts Life Cycle in ADF applications

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 <domain-home>/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 <domain-home>/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.migration</param-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.removal</param-name>

<param-value>OFF</param-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 <domain-home>/config/fmwconfig folder.

The following weblogic-application.xml properties govern how (and if) they're deployed.

<listener>

<listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener</listener-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.migration</param-name>

<param-value>[MERGE|OVERWRITE|OFF]</param-value>

</application-param>

• MERGE: migrate non-existing credentials only;
• OVERWRITE: overwrites existing credentials;
• OFF: skips credentials migration;

Identity Propagation in a flow involving OAM, OSB and web services

A Sales Consultant asked for my opinion in a scenario where a customer wants to propagate end user credentials all the way from OAM (Oracle Access Manager) to web services responsible for executing business logic.

In the customer flow, after being authenticated by OAM, the end user is redirected to a portal UI. The UI makes calls to OSB (Oracle Service Bus) which in turn invokes web services deployed on WebLogic Server. One of use case driving requirements is that the end user identity should be available for underlying web service implementation so that it can be recorded in database tables for auditing purposes. Therefore, the main question here is how to get the user identity from OAM token and make it available for web service implementation code.

OAM is a web-based SSO solution. Very roughly put, it works by means of an HTTP cookie called ObSSOCookie which is recognized by OAM's Policy Enforcement Points, known as Web Gates. A Web Gate intercepts all HTTP requests for a protected resource and evaluates whether an ObSSOCookie is present and valid, in which case the user is considered authenticated.

OSB is an SOA integration component within Oracle's SOA portfolio. It provides routing, transformation and mediation capabilities for interactions between heterogeneous services.

Ok, to the solution.

Let's first talk about what happens when an anonymous user accesses the protected portal UI page. Anonymous users don't hold an authenticated ObSSOCookie (note that anonymous users might hold an ObSSOCookie, but for the default OblixAnonymous user), therefore are challenged by OAM's Web Gate according to the configured authentication scheme.

Let's assume in this case a form-based scheme requiring username and password is set. When challenged, the user types in her username and password. Assuming those are correct, an ObSSOCookie identifying the end user is generated and added to the HTTP response. The end user is granted access and directed to the protected resource (portal UI page). Once the user lands on the portal UI page, a call is made to a web service running on a remote WebLogic Server via OSB.

At this point we need to make an important decision: how to retrieve the end user identity and move it forward. Remember that so far it only exists within the ObSSOCookie that is present in the HTTP request. There are two ways to accomplish it: Within the portal UI, i) the ObSSOCookie can be added to an Oracle proprietary SOAP header or ii) the end user identity can be obtained from portal application container's Java Subject and added to a standard SAML message within the SOAP header. In any case, an OAM identity asserter must be configured in WebLogic Server running the portal application. OWSM (Oracle Web Services Manager) also plays a vital role from now on. An OAM identity asserter basically asserts the end user identity present in ObSSOCookie against the configured Identity Store in WebLogic Server. If assertion succeeds, the user principals are added to the container's Java Subject.

OWSM is a key component in Oracle's SOA solution. It provides centralized definition and distributed enforcement of security and management policies for SOA and JavaEE applications. OWSM runtime modus operandi is very simple: simply put, agents installed at specific endpoints intercept and evaluate SOAP calls according to rules specified by attached policies. Policies come in two flavors: client-side and server-side. Client-side policies usually add data to the SOAP message while server-side policies retrieve that data and process them, many times delegating decisions to other third-party mechanisms.

Back to our flow, I recommend approach ii) as the means of propagating the end user identity. For two reasons: a) we're avoiding adding proprietary data to the SOAP message. If one decides for i), on the server side she needs to provide for understanding that proprietary data. Even considering that OWSM natively supports it, the implementation would stay tied to necessarily understanding ObSSOCookie. If your organization standardizes on SAML (Security Assertions Markup Language), for example, that might be a problem. b) OAM is unlikely to be available in a development environment, therefore relying on ObSSOCookie would simply not work. Once the ObSSOCookie is asserted, a Java Subject becomes available within WebLogic Server.

By attaching a SAML-based OWSM client-side policy to the calling endpoint, the OWSM agent will pick the principal from the Java Subject, generate a SAML message and add it to the SOAP header.

There are several options on how the SAML message can be generated: as clear-text, with message-level security (WSS) or sent through an SSL channel. I will cover the details of message-level and transport-level security in OWSM in a subsequent article.

At this point we're making a SOAP call and we've added a SAML token to the SOA header. Next element in our flow is OSB. The key point here is that we don't need to process that token in OSB. All that's required is having OSB configured in pass-through mode and the request will get intact to the invoked web service. On the web service, we attach a SAML-based OWSM server-side policy that is capable of understanding the token generated by the client-side policy. The policy extracts the token and submits it for processing, which in this case means asserting the end user identity against the identity store configured for the WebLogic Server hosting the web service. If the user is successfully asserted, a Java Subject is created and made available to running applications. One can use JAAS APIs to get the authenticated user name and stick it into any DML statements that are executed against a database.