WebSeal comes with a local app these days, that can show you if a particular user (credential) would have access to a WebSEAL resource.

To enable the application, add it to your WebSEAL configuration file, under the local-apps stanza.

azn-decision = aznapi

Here’s the documentation about the application: https://www.ibm.com/docs/en/sva/10.0.5?topic=applications-authorization-rest-api.

This comes in handy, and if you have a tool like Postman, it can be useful to quickly verify your ACL and POP settings. Furthermore, this tool also gives the results for the (newer) API Access Control settings (which also create POP’s and ACL’s under the cover).

But if you are in a situation where you need to enable developers or product managers of backend applications to make sure the access control is set correctly, this is not very easy, because you need to have intimate knowledge of how the Policy database works in WebSEAL.

So we can provide a simple wrapper web application that does that for use:

This demo application utilizes some Carbon Design components (https://carbondesignsystem.com/) and simply calls the azn-decision WebSEAL local app. Since I’ve installed it on WebSEAL, I can avoid CORS configurations.

NOTE The goal of this tool is to assist developers in testing their applications. So this is not suitable in this setup for a production environment !


Local application

We obviously need to configure the azn-decision local application on WebSEAL (see higher).

ACL settings for this app

I’ve put an unauthenticated ACL on the /aznapi endpoint.

I’ve got the isam_authsvc_unauth acl here - but you’ll only have this if you ran the AAC wizard earlier.

Content Security Policy

To allow the Carbon Design elements to be retrieved from the CDN, a CSP like below is necessary. Of course a better, safer way to deal with this, is to copy the sources to a location under your own control (under your own domain)

The same goes for the unsafe-inline, which you should avoid.

http-rsp-header = Content-Security-Policy:TEXT{default-src 'self'; script-src 'self' 'unsafe-inline' https://1.www.s81c.com/; style-src 'self' 'unsafe-inline' https://1.www.s81c.com; style-src-elem 'self' 'unsafe-inline' https://1.www.s81c.com; style-src-attr 'self' 'unsafe-inline' https://1.www.s81c.com; font-src 'self' https://1.www.s81c.com; form-action 'self'}

Upload the wrapper application to WebSEAL

The source files of the application are here: https://github.com/Bozzie4/blog_assets/tree/main/Isva_Carbon_Pages/aznapi.

You need:

  • aznapi.js : the javascript code that performs the actual call to WebSEAL (using the Fetch API)
  • aclchecker.html : the html file to open

You will probably want to change the WebSEAL Object name to match your situation.

I put both these files in the pkmspublic folder in the Management Root.

This means the files are accessible by unauthenticated users (no ACL is necessary).

Example : POP

I created a POP through WebSEAL’s API Access Control Policies.

This is an example of a custom attribute that should be part of the user’s credential before he’s granted access.

This is similar to IAG’s authorization model (https://docs.verify.ibm.com/gateway/docs/yaml-authorization-rules), which is more geared towards using any attribute in a credential as is likely in OAuth scenarios.

Anyway, the result in the Policy database is this POP:

And I can just add this POP to an Object in my WebSEAL ObjectSpace:

Now I can veriy that my user1 would not have access , if the customAttribute is not present. The application is available on https://mywebseal.domain.tld/pkmspublic/aclchecker.html.

The attributes output gives an indication why the user doesn’t have access ( {"AZN_PERMINFO_FAIL_REASON":"268809260"}).

And if the customAttribute is there, I know my user1 will have access !

Future enhancements

This application still requires a user to know some of the internal details. This application should just fill in the correct technical details for the user:

  • the actual name of the WebSEAL object is likely not relevant, just the uri (eg. /jct1)
  • supply some presets (eg. for a user that is member of specific groups)
  • I’ve not yet figured out how to use this for an unauthenticated user.

IBM Application Gateway

The same local app is also a part of IAG (https://www.ibm.com/docs/en/iag/23.10.0?topic=server-local-applicationsauthorization-decision). This means that we can use this same simple application , to check authorizations on IAG as well !

Errors encountered

I ran into this error, while executing the REST POST call from within JavaScript. This error does not occur when using a REST API tool (Postman), so I’m a bit surprised.

2023-10-06-13:27:20.434+00:00I----- 0x38CF0460 webseald ERROR wwa http HTTPParser.cpp 894 0x7fa771040700 -- DPWWA1120E   The POST body of the client request contains misformated or invalid data

The solution for this error is to remove everything related to worklight from the azn-decision-info stanza. This stanza is only filled when you activated the Advanced Access Control for the reverse proxy.

I’ve commented the lines out in this example:

#urn:ibm:security:worklight:adapter:parameters = post-data:parameters
#urn:ibm:security:worklight:device:id = header:x-wl-device-id
#urn:ibm:security:worklight:version:app = header:x-wl-app-version
#urn:ibm:security:worklight:version:platform = header:x-wl-platform-version
#urn:ibm:security:worklight:adapter:adapter = post-data:adapter
#urn:ibm:security:worklight:adapter:procedure = post-data:procedure
#urn:ibm:security:worklight:version:native = header:x-wl-native-version