A Further Introduction to Oracle IDM and Fusion Apps

Last week I gave an introduction into the Fusion Middleware Security in Fusion Applications.  This week I’d like to expand on that introduction to talk specifically, but still at a high level, about how the the Oracle IDM products fit in Fusion Apps.  To review, here I’m talking specifically about OID, OVD, OAM, OIM, and optionally OIF.

Active Participants

If you are going to take anything away from what I have written or will write about Fusion Apps and IDM let it be this: Do not ignore the Identity and Access Management components of Fusion Applications or take them for granted.

Even more than the other FMW components in Fusion Apps, the IDM components are not black boxes. They are independent products that must be actively managed.

Independently Installed
This starts at the very beginning with the fact that unlike the other FMW components, the IDM components of Fusion Apps is installed separately from the actual Fusion Apps kit. In fact, what I like to call the IDM environment for Fusion Apps is a pre-requisite to the Fusion Apps install itself which in turn asks approximately 100,000 questions about the IDM environment that it will be leveraging. This IDM environment includes its own database and web tiers which are distinct from the Fusion Apps database and web tiers.

This process is really just a specific build out of the Oracle IDM Suite, very similar to what an Oracle IDM Suite customer might do for a traditional enterprise deployment.

So, to successfully deploy Fusion Apps, you must be able to successfully deploy the Oracle IDM suite.

Mission Critical
The IDM components of Fusion Applications are mission critical. If OVD, OID, or OAM aren’t working properly (or God forbid, aren’t working at all) then neither is Fusion Apps. It is that simple.

So, if you want a high available deployment of Fusion Apps, you better make OVD, OID, OAM, and OIM highly available.

If you want to be able to restore a backup of your Fusion Apps environment, you better know how to back the IDM components.

If you want to be able to monitor the health status of your Fusion Apps deployment, you better include the IDM components in that monitoring.

Smart people involved in the deployment and/or management of Fusion Apps will recognize this and give proper attention to deploying and tuning the IDM environment for Fusion Apps in a way that is consistent with the requirements for the total FA deployment.

Skill Sets You’ll Want to Have
During a Fusion Apps deployment and the build out of the IDM environment that is a part of that deployment you’ll want to be able to:

• Understand the deployment options described in the IDM Enterprise Deployment Guide (Fusion Apps Edition).
• Be able to use that guide to architect an appropriate IDM build out for your specific Fusion Apps requirements.
• Be able to install OID, OVD, OAM, OIM, and optionally OIF; along with the related pre-requisite and auxiliary packages such as SOA suite, WLS, and OHS.
• Be able to tune all the above components.
• Be able to do basic configuration of each of the listed components. The specifics of what this means varies from component to component and even deployment to deployment.

On an ongoing basis you’ll want to be able to:

• Enable and analyze debug logging for each component.
• Monitor each component using Enterprise Manager (EM) or integrate the component with an existing monitoring framework in your enterprise.
• Be able to take backups of the IDM environment.
• Be able to start and stop each component.
• Be able to patch each component.
• Finally, you’ll still want to have basic configuration and administration knowledge for each component around for expected and unexpected changes and maintenance.

Conclusion
While being able to author complex OAM policies, write custom OVD adaptors, or create complex SOA composites for custom OIM approvals isn’t necessary for most if not all Fusion Apps projects; a foundational proficiency with the Oracle IDM stack where one can install, manage, and monitor each IDM product is required for a successful and stable deployment of Fusion Apps.

In the coming weeks I plan to write more about how to plan for, execute, and verify a successful IDM build out for Fusion Apps.

OIM 11g & LDAP Synchronization

Since the first OIM 11g release, one of the frequently asked questions about OIM 11g is:

• Should I configure OIM with LDAP synchronization or should I deploy a LDAP connector?

Since earlier versions, OIM provides connectors for the most popular LDAP systems: Oracle Internet Directory (OID), Oracle Directory Server EE (formerly Sun Java Directory/iPlanet), Novell eDirectory and Microsoft Active Directory (AD).

With OIM 11g, a new feature called LDAP synchronization was introduced. OIM uses this feature to synchronize its users and roles base to a LDAP system. This synchronization is bidirectional and it uses scheduled jobs/reconciliation engine to pull changes from LDAP and event handlers to push data to LDAP.
But if OIM already provides a connector for most of the industry LDAP servers, why provide a feature like LDAP Synch? Different customer’s business requirements, customer feedbacks and also some technical reasons led Oracle to develop this feature and make it available out-of-the-box in the product.

Fusion Security – Apps Edition

When we first started this blog more than 2 years ago, we debated about whether to name it “Fusion Security” or more specifically “Fusion Middleware Security”. We all work in the Fusion Middleware team on Fusion Middleware but even back then we saw Fusion Applications coming down the pipe and after all Fusion Apps is a set of big business applications whose principal distinction (in my opinion) is that it is the first set of business applications to be built on a truly modern middleware platform.

The much anticipated Fusion Applications was recently released. For those of you unfamiliar with Fusion Apps, it is composed of several families of applications (CRM, Financials, HR, Supply Chain, Procurement etc) that comprise the next generation version of Oracles Apps portfolio (PeopleSoft, E-Business Suite, Siebel etc.) and as I said it is built on top of most of the Fusion Middleware products that currently exist today.

Welcome Apps Community

I will start off by welcoming those in the Oracle Apps community to the Fusion Middleware community and specifically the FMW security community. The middleware products may seem complicated, even overwhelming at first, but they are good powerful products that you can build your business upon.

Why You Should Care

What does this mean for those of us in the Fusion Middleware Security community? Why should we care?

For one Fusion Apps has been driving much of the direction of Fusion Middelware for some time and now is your opportunity to see what it is all about and how the Middleware you know and love is used. In this post I’ll provide an overview of this usage and follow up with much more detail in the coming months.

Secondly, I think our community is about to get much larger. Every Fusion Apps customer will become a Fusion Middleware Security Customer. So, I’ll also take the opportunity now to say welcome to all the new Fusion Apps architects, developers, and administrators out there that may happen across this post.

Thirdly, Fusion Applications is a very large and complex set of applications. Oracle has created an Enterprise Deployment Guide specifically discussing how the Identity Management products that Fusion Apps utilizes should be deployed. It is worth reading this just to get an idea for what Oracle considers as reference architecture for an IAM environment that supports large business applications.  You can find the Enterprise Deployment Guide for Oracle Identity Management (Fusion Apps Edition) here.

I myself have been very involved in the initial rollout of Fusion Applications and will continue to be very much involved along with other members of this blog in helping to advise customers on the security technology involved in Fusion Apps deployments.

What This Doesn’t Mean

With all that being said, while I do think the release of Fusion Applications is exciting and important to those of us in the Fusion Middelware Security community, I have heard some messaging around Fusion Applications and its impact on Fusion Middleware that I think oversells the importance of Fusion Apps and is ultimately incorrect.

I’ve heard it said many times that customers should closely align their use of our Fusion Middleware products to how they are used in Fusion Applications. While I agree that customers should be mindful of how FMW is used in Fusion Apps, I simply don’t agree with that statement.

Fusion Applications is a set of specific applications, namely business applications, which use our Fusion Middleware Security stack in a specific set of ways. They do not make use of every feature or even every product in our FMW Security stack. Our Fusion Middleware customers use our middleware products in a wide variety of ways, to create and support a wide variety of applications, with a wide array of business requirements, in a large variety of environments. Some of the differences between what our customers are trying to achieve with Fusion Middleware vs. what we achieved with Fusion Middlware in Fusion Apps means that customers can and should take different approaches from what was taken with Fusion Applications.

What FMW Security Is In Fusion Apps

Now that my rant is out of the way, I’ll proceed to talk about how Fusion Middleware Security is used in Fusion Applications on a product by product basis. Again, for a more detailed discussion at this time see the Enterprise Deployment Guide for IDM (FA Edition).

• Oracle Internet Directory (OID) serves as the store for OPSS security policies and as the default store for Fusion Apps users.
• Oracle Virtual Directory (OVD) serves as a go-between layer for user stores when OID is not being used (and optionally when OID is being used. It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory.
• Oracle Access Manager (OAM) provides authentication and singles sign-on (SSO) for Fusion Apps. It is worth noting that OAM runs in a special mode in Fusion Apps build outs and does not by default provide authorization, even course grained, for Fusion Apps. This means that some careful consideration will have to be done by customers wanting to use a single OAM deployment for Fusion Apps and other applications in their environment.
• Oracle Identity Manager (OIM) helps provision users to the FA environment and provides delegated management and self service user management services to the Fusion Apps environment.
• Oracle Platform Security Services (OPSS) provides the fine grained authorization for the application in Fusion Apps as well as an assortment of other functions such as LDAP connectivity and key management.
• Oracle Web Services Security Manager (OWSM) provides web services security (WS-SEC) for both FA internal web services communication and the external web services interfaces to FA.
• WebLogic Server serves as the core container for Fusion Apps and so WLS security is part of the picture. Specifically, identity asserters and authenticators (SSPI providers) are configured in FA. Other WLS security areas such as transport (SSL) security and node manager security also come into play.
• Oracle HTTP Server (OHS) serves as the web tier for Fusion Apps. There are actually two web tiers in a Fusion Apps deployment. The first web tier is the front end to the IDM environment and the 2nd is the front end to the Fusion Apps themselves. Both web tiers will have OAM webgates on them. Beyond that SSL is the main security consideration you will have to configure / manage.
• SOA Suite – SOA Suite is widely used throughout Fusion Apps including (as most of you know) its use as the workflow engine for OIM. There is a good deal of security in SOA Suite to manage including transport and message level security.

Weblogic WS-Trust Client and OWSM interoperability

First, I’d like to take the opportunity to wish you all our readers a great 2012, with plenty of health, joy, care for each other and peace! We really appreciate your interest in our posts and hope to be truly contributing to your daily work. With that said…

Did you guys know Weblogic implements a WS-Trust client?  Did you also know that WS-Trust client can interoperate with web services protected by OWSM policies requiring message protection (signing and encryption) ? Those were very helpful to me in satisfying some important requirements for a customer in a recent proof of concept exercise.

This is a long post. It describes a bunch of things that are more or less available across several official books, but also adds some details that are not easily found, especially if you’re interested in troubleshooting.

The customer adopts OSTS (Oracle Secure Token Service) and wanted an alternative to OWSM (Oracle Web Services Manager) client. OSTS is part of Oracle IAM Suite 11.1.1.5, delivered as an OAM (Oracle Access Manager) add-on. For an introduction to OSTS, check this post.

OSTS leverages OWSM policies to protect its WS-Trust endpoints. OWSM 11.1.1.5 also delivers WS-Trust client policies. When your web services clients can leverage the OWSM WS-Trust client policies, great, it just works. In situations where they can’t, alternate solutions need to be thought. This particular customer had a considerable amount of clients running in Weblogic server 10.3.3, where WS-Trust support is not available in the OWSM runtime. We could have looked at web services frameworks like Apache’s AXIS2 or CXF, but Weblogic’s WS-Trust client was just there, waiting to rescue. As you can see if you follow this post, it saved us quite some coding.

I must say that the approach describe here is by no means a recommended architecture for everyone. Every customer scenario is different and should be thought in light of current and future requirements. I must also say that OWSM is the strategic direction and, as such, should always be the preferred approach.

This is basically what I’ve helped the customer to achieve:




Here are the interaction details:

1) The client makes an RST (Request Secure Token) using Weblogic’s WS-Trust client to the OSTS requesting for a SAML token to be sent to the ws provider. The client identifies itself to the OSTS with username token credentials in the WSS header, but requests a token on behalf of someone else. In this example, on behalf of the client application executing user.

2) OSTS’ OWSM agent validates the WSS part of the request. It needs to decrypt the message and validate the digital signature added by Weblogic’s WS-Trust client. This is where most of interoperability problems arise. The policy attached to OSTS endpoint is oracle/wss11_username_token_with_message_protection_service_policy

3) After doing some extra validation on the RST and the requestor credentials, the OSTS issues the SAML token (RSTR – Request Secure Token Response).

4) The client calls the ws provider passing the issued SAML token along. SAML confirmation method in this case is Sender-Vouches, which means the ws client signs the SAML token. The policy attached to ws provider is oracle/wss11_saml_token_with_message_protection_service_policy.

5) The ws provider sends the response.

Implementation Details

1) Web Service Proxy

Web service JAX-WS proxy is generated for the web service provider as usual. This is done by Weblogic’s clientgen tool via an ANT build script, as shown below:

<project name="ws-client" default="build">

 <property name="wls.hostname" value="localhost"/>

<property name="wls.port" value="9003"/>
<property name="classes-dir" value="classes"/>
<property name="src-dir" value="src"/>
<path id="client.class.path">
<pathelement path="classes"/>
<fileset dir="${mw.home}/wlserver_10.3/server/lib">
<include name="weblogic.jar"/>
<include name="wseeclient.jar"/>
</fileset>
<pathelement path="${java.class.path}"/>
</path>
<taskdef name="clientgen" classpathref="client.class.path" classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<target name="build">
<clientgen wsdl="http://${wls.hostname}:${wls.port}/webservices/GreetingPort?WSDL"
destDir="${src-dir}"
packageName="ws.client"
type="JAXWS"/>
<javac srcdir="${src-dir}" destdir="${classes-dir}" includes="**/*.java"/>
</target>
</project>

Notice that you need weblogic.jar and wseeclient.jar in the CLASSPATH to run clientgen. These files are located under $MW_HOME/wlserver_10.3/server/lib folder.

You don’t generate proxies for the OSTS endpoint. This is implicitly taken care by WLS WS-Trust client.


2) Client Code

My client is a simple servlet, that actually hides some serious heavy-lifting performed by Weblogic’s WS-Trust client. The code is commented so it explains itself. Look at how simple it is.

You get an instance of the proxy port as you would normally do and add a couple of properties to the BindingProvider object in order to make the WS-Trust client invoke OSTS (lines 35-45).

1: package trunk.interop.ws;

2: 

3: import java.io.IOException;

4: import java.io.PrintWriter;

5: import javax.servlet.*;

6: import javax.servlet.http.*;

7: import javax.xml.ws.BindingProvider;

8: import java.util.Map;

9: import weblogic.wsee.message.WlMessageContext;

10: import weblogic.wsee.jaxrpc.WLStub;

11: import weblogic.wsee.security.WSEESecurityConstants;

12: import javax.xml.soap.SOAPConstants;

13: import ws.client.Greeting;

14: import ws.client.GreetingService;

15:

16: public class TrustClientServlet extends HttpServlet {

17:

18: private static final String CONTENT_TYPE = "text/html; charset=windows-1252";

19: private static final String TRUST_VERSION = "http://docs.oasis-open.org/ws-sx/ws-trust/200512";

20: private static final String STS_URL = "http://dogwood.us.oracle.com:14100/sts/wss11user";

21: private static final String STS_POLICY = "StsWss11UntPolicy.xml";

22: public void init(ServletConfig config) throws ServletException {

23: super.init(config);

24: }

25: public void doGet(HttpServletRequest request, HttpServletResponse response)

26: throws ServletException, IOException {

27:

28: response.setContentType(CONTENT_TYPE);

29: PrintWriter out = response.getWriter();

30: out.println("<html>");

31: out.println("<head><title>TrustClientServlet</title></head>");

32: out.println("<body>");

33: GreetingService service = new GreetingService();

34: Greeting port = service.getGreetingPort();

35: Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();

36: // Oracle STS endpoint URL

37: requestContext.put(WLStub.WST_STS_ENDPOINT_ON_SAML, STS_URL);

38: // WS-Policy to talk to Oracle STS

39: requestContext.put(WlMessageContext.WST_BOOT_STRAP_POLICY, this.getClass().getResourceAsStream(STS_POLICY));

40: // WS-Trust version

41: requestContext.put(WSEESecurityConstants.TRUST_VERSION, TRUST_VERSION);

42: // SOAP version

43: requestContext.put(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE);

44: // username for whom a token will be requested

45: requestContext.put(WSEESecurityConstants.ON_BEHALF_OF_USER, request.getRemoteUser());

46: out.println(port.sayHello(request.getRemoteUser()));

47: out.println("</body></html>");

48: out.close();

49: }

50: }

3) OWSM Policy in the OSTS endpoint

Line 20 defined the OSTS endpoint. If you append ?WSDL to it and paste it in a browser URL, you can see the WS-Policy generated by the OWSM policy (wss11_username_token_with_message_protection_service_policy) that protects it. It can give you very good insights in case you run into interoperability issues.

In my experience, the interoperability problems are mostly due to mismatch between security bindings, encryption method mechanisms and encryption algorithms.

Here are some typical error messages. I now know how to make them happen anytime. :-)

a) Due to security binding mismatch:

Caused by: 
oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00059 : Signature method algorithms are mismatched. Expected : http://www.w3.org/2000/09/xmldsig#hmac-sha1, 
Actual : http://www.w3.org/2000/09/xmldsig#rsa-sha1.

In this case, make sure both policies use the same security binding. For instance, OWSM’s wss11_username_token_with_message_protection_service_policy is Symmetric. The security binding is NOT configurable in the OWSM policy.

<sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">

  <wsp:Policy>
  ...
</sp:SymmetricBinding>

b) Due to encryption reference mechanism mismatch:

[2011-09-21T16:04:27.900-07:00] [ms1] [ERROR] [WSM-00034]

[oracle.wsm.resources.security] [tid: [ACTIVE].ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 
5f5492695bd28c21:-83db949:1328e2f9215:-8000-000000000000002c,0] 
[WSM_POLICY_NAME: 
oracle/wss11_saml_token_with_message_protection_service_policy] [APP: 
InteropWebServices] Error in Encryption reference mechanism compliance : 
Expected : thumbprint , Actual : ski. Ensure that a compatible policy is 
attached at the client side.

This is configurable in the OWSM policy, by changing the orasp:enc-key-ref-mech property value.

<orasp:wss11-username-with-certificates orawsp:name="WS-Security 1.1 username

with certificates" orawsp:Silent="false" orawsp:Enforced="true" 
orawsp:category="security/authentication, security/msg-protection">
 
 <orasp:username-token orasp:password-type="plaintext" 
orasp:add-nonce="false" orasp:add-created="false"/>
  
<orasp:x509-token orasp:enc-key-ref-mech="ski"/>
  
<orasp:msg-security orasp:confirm-signature="true" 
orasp:sign-then-encrypt="true" orasp:include-timestamp="true" 
orasp:encrypt-signature="false" orasp:algorithm-suite="Basic256">

c) Due to encryption algorithms mismatch:

Caused by:

oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00030 : The encryption method key wrap algorithms do not match : Expected 
: http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p, 
Actual : http://www.w3.org/2001/04/xmlenc#rsa-1_5.

This is also configurable in the OWSM policy. In the policy snippet above, you can play with the property value of orasp:algorithm-suite and try the Algorithm Suite values as specified in the WS-SecurityPolicy specification. Make sure it matches the one in the client-side policy.

Note: In OSTS, the OWSM policies are available at $MW_HOME/Oracle_IAM1/oam/server/policy/sts-policies.jar.


4) Client-side WS-Policy for OSTS endpoint

Weblogic web service client APIs are smart enough to infer the necessary client configuration from the advertised WS-Policy in the web service WSDL. That said, we’re NOT supposed to attach any client-side policies to talk to our web service provider endpoint. However, this does NOT apply when talking to an STS using the WS-Trust client.

Notice that my client code adds StsWss11UntPolicy.xml to the BindingProvider on line 39. The xml file actually defines the WS-Policy that interoperates with OSTS endpoint protected by OWSM (once I worked through the problems showed above). Here it is:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireKeyIdentifierReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256Rsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
<sp:SignedParts>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>

5) Required Configuration in Weblogic server

I’ve been always curious on how to define credential mappings in Weblogic to be used in the context of web services. Time has come. It turns out the system properties in the Troubleshooting section (next) came up very handy to let me know the mappings to be defined.

A credential mapping essentially maps a principal to a credential to be used when talking to external systems. This is very prevalent when the external systems are based on a JCA adapter. But it  applies to web services as well. For example, given authenticated user “andre” (known as the initiator) wants to call web service http://server:7003/webservices/GreetingPort from within a web service client running in Weblogic server, a credential mapping would tell which credentials the user would have to communicate with the web service.

A web service client running in Weblogic is “aware” of the security services provided by the server. In this case, given the WSS requirements stated by our 2 web services (OSTS and ws provider), two types of credential mappings are required in Weblogic:

A) 1 Default Credential Mapping:

Maps an initiator to a username/password pair. Required to add a username token to the outgoing SOAP request when calling the OSTS endpoint. A Default Credential Mapper is OOTB available in Weblogic. We DON’T need a mapping to talk to web service provider endpoint because that one requires a SAML token, which is going to be retrieved from OSTS.

Here’s the credential mapping (Security Realms –> myrealm –> Credential Mappings –> Default > New):




Protocol + Remote Host + Remote Port + Path makes up the web service URL being called. You don’t need to specify any value for Method. Notice that Path value must start with a /.





Local User is the initiator, on whose behalf the username under Remote User field is going to be retrieved. Obviously, the Remote User needs to be properly authorized in the remote system (OSTS).

B) 4 PKI Credential Mappings:

A PKI Credential Mapping maps an initiator to either a private key or a certificate. Required to perform digital signature and message encryption when calling the OSTS endpoint and web service provider endpoint. Remember, both endpoints require message protection. A PKI Credential Mapper is NOT OOTB available in Weblogic. To add one, got to Security Realms –> myrealm –> Providers –> Credential Mapping –> New (pick PKICredentialMapper). Make sure to fill in the form in the Provider Specific tab.





The keystore file Name is relative to the location where you start the Admin server. In my case, I’ve simply put clientkeystore.jks in $MW_HOME/user_projects/domains/<my-domain-name> folder.

Once you add it, restart the Admin Server so you can add the mappings (Security Realm –> myrealm –> Credential Mappings –> PKI –> New). Here are my 4 mappings:




Notice there are 2 mappings for each endpoint. One to retrieve the private key used for signing and one to retrieve the certificate used for encryption. When defining these mappings, you have the opportunity to inform the alias names in the keystore (clientkeystore.jks) holding the private key and the certificate.


6) Troubleshooting

When running into trouble, these 4 system properties will come to your rescue in the client side. Add them to EXTRA_JAVA_PROPERTIES in setDomainEnv.sh:

• weblogic.xml.crypto.dsig.verbose=true
• weblogic.xml.crypto.encrypt.verbose=true
• weblogic.xml.crypto.keyinfo.verbose=true
• weblogic.xml.crypto.wss.verbose=true

You should be able to detect, for example, why you’re not able to get a X509 token.

####<Oct 10, 2011 2:55:58 PM PDT> <Debug> <SecurityCredMap> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
<> <aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758414> <BEA-000000> <getCredentials: requestor=Subject: 
1
 Principal = 
weblogic.security.principal.WLSKernelIdentity("<WLS Kernel>")
, 
resource=type=<remote>, protocol=http, remoteHost=localhost, 
remotePort=9003, path=/webservices/GreetingPort, initiator=Subject: 
1
 Principal = 
weblogic.security.principal.WLSUserImpl("andre")
, 
credType=weblogic.pki.TrustedCertificate>
####<Oct 10, 2011 2:55:58 PM PDT> <Info> <> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> 
<andre> <> 
<aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758417> <BEA-000000> <Did not get token for token type http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 
and purpose encrypt from token 
handlerweblogic.xml.crypto.wss11.internal.bst.BSTHandler@9527ee>

Thanks to those properties, the log message above tells it was not possible to get a X509 token for user andre to encrypt the message. Then adding a PKI Credential Mapping with the server certificate solves the problem.

And to troubleshoot OWSM, configure TRACE:32 logging level for oracle.wsm in $MW_HOME/user_projects/domains/<domain-name>/config/fmwconfig/servers/<server-name>/logging.xml:

<logger name='oracle.wsm' level='TRACE:32' useParentHandlers='false'>

<handler name='owsm-message-handler'/>
</logger>

Log messages are sent, by default, to $MW_HOME/user_projects/domains/<domain-name>/servers/<server-name>/logs/owsm/msglogging/diagnostic.log.

Happy 2012!!