{"id":179,"date":"2025-04-17T19:01:16","date_gmt":"2025-04-17T19:01:16","guid":{"rendered":"https:\/\/www.familie-kleinman.nl\/brain\/?p=179"},"modified":"2025-04-17T20:01:17","modified_gmt":"2025-04-17T20:01:17","slug":"oracle-wsm-jwt-and-custom-policies","status":"publish","type":"post","link":"https:\/\/www.familie-kleinman.nl\/brain\/index.php\/2025\/04\/17\/oracle-wsm-jwt-and-custom-policies\/","title":{"rendered":"Oracle WSM, JWT and custom policies"},"content":{"rendered":"

This is the second post in a series on OSB, JWT and OWSM. In the first<\/a> post, I explained how to implement JWT validation using the standard OWSM configuration.<\/p>\n

Introduction<\/h2>\n

However, there\u2019s a fundamental limitation to that approach:\u00a0 you can\u2019t create fine-grained access control \u2014 for example, allowing token X to access service Y, but not service Z. As long as the token is valid, it grants access to all secured services using the same policy.<\/p>\n

That\u2019s why I wanted to create a custom policy \u2014 to add fine-grained access control to individual services. At first, things looked promising. Oracle provides a good example of a custom policy that limits access based on IP address \u2014 you can apply it to a specific proxy and define allowed IPs, and can be easily attached to a SOAP\/WSDL proxy service.<\/p>\n

However, when I tried attaching this policy to a REST or ANY\/XML proxy, I ran into this error:<\/p>\n

[OSB-398128] <\/strong>One of the Web service policy attached is not allowed on service TEST\/TestProxy because the service binding does not support it.<\/p>\n

For that reason, I opened a Service Request (SR) with Oracle, explaining that OWSM custom policies don\u2019t work on REST and ANY\/XML proxies. Oracle Support was responsive and helpful \u2014 and they did find an answer.\u00a0 Unfortunately, it wasn\u2019t the one I was hoping for: They pointed to an outstanding enhancement request. Their response confirmed that attaching custom policies to REST or ANY_XML proxies isn\u2019t supported.<\/p>\n

Luckily, I kept working on the JIRA ticket while the SR was open.<\/p>\n

Spoiler alert: I got it working!<\/strong><\/p><\/blockquote>\n

In this blog post, I\u2019ll walk you through how I got it to work \u2014 step by step \u2014 and how you can implement your own custom policies and attach them to REST and ANY\/XML services in OSB.<\/p>\n

Oh, and this isn\u2019t just about JWT.\u00a0 This workaround will likely work for any<\/em> custom policy you want to attach to a REST or ANY\/XML proxy.<\/p>\n

Disclaimer<\/h2>\n

This solution was tested and validated on Oracle Service Bus 12c (12.2.1.4). At the time of writing, I haven\u2019t tested it on 14c yet \u2014 that work is in progress. I\u2019ll update this post (or write a follow-up) once I\u2019ve confirmed compatibility with 14c. The example code has been cleaned and modified to avoid exposing proprietary details.<\/p>\n

It serves as a proof of concept, not a production-ready implementation \u2014 you\u2019ll need to adapt it to your own environment.<\/p>\n

Important:<\/strong> This approach is NOT<\/strong> officially supported by Oracle. Use it at your own risk and discretion.<\/p>\n

I got lucky?<\/h2>\n

Honestly, if I have seen the enhancement request beforehand, I probably wouldn\u2019t even have picked up the ticket. But I didn\u2019t know. I was just being stubborn, curious, and \u2014 let\u2019s be honest \u2014 a bit lucky. Sometimes not knowing something is “impossible” is the best way to get it done.<\/p>\n

The key to making this work was something surprisingly simple:<\/p>\n

You can’t export internal Oracle policies directly. But you can<\/em> clone them. And once you’ve cloned an internal policy, you’re free to download it, see its contents and modify it. By adding a reference to your own custom Java class and giving the policy a new name, it suddenly becomes attachable to REST services \u2014 and it works.<\/p>\n

My proof of concept was based on just that:<\/p>\n

    \n
  1. I exported a standard internal policy as-is. ( oracle\/http_jwt_token_service_policy<\/strong> )<\/li>\n
  2. I modified a few properties<\/li>\n
  3. I added a single element to trigger my Java class.<\/li>\n
  4. That was it. That small change made the difference. And it executed as expected.<\/li>\n<\/ol>\n

    Step 1. Export cloned policy<\/h2>\n

    First, open <yourhost:yourport\/em><\/code> and navigate to Weblogic Domain -> Web Services -> WSM Policies<\/p>\n

    \"\"<\/p>\n

    Select the oracle\/http_jwt_token_service_policy<\/code> and click Create Like<\/strong> in the top bar.<\/p>\n

    \"\"<\/p>\n

    Give your copy a meaningful name \u2014 adjust the name, display name, and description as needed.<\/p>\n

    Next, locate the copy you just created, click Export<\/strong>, and save the resulting ZIP file somewhere on your local drive.<\/p>\n

    Step 2. Modify the policy XML<\/h2>\n

    Locate the ZIP file and extract its contents. Inside, you\u2019ll find a META-INF<\/code> directory, and within that, a policies<\/code> directory. That\u2019s where your exported policy lives.<\/p>\n

    Start by renaming policy.xml<\/code> to something more meaningful \u2014 for example: proofofconcept_policy.xml<\/code>, or whatever fits your naming convention.
    Then open the file in a text editor such as Notepad++.<\/p>\n

    Next, remove both “Logging” sections \u2014 they serve no purpose in your custom policy and can be safely deleted.<\/p>\n

    There are several parts in the file that need to be modified:<\/p>\n

    1. Update the <wsp:Policy><\/code> attributes:<\/strong><\/p>\n