API Connect

 View Only
Expand all | Collapse all

User Defined Policy - JWS | Crypto Object Reference understanding required

  • 1.  User Defined Policy - JWS | Crypto Object Reference understanding required

    Posted 23 hours ago

    Hi everyone,

    I am currently working on implementing JWS and JWE using IBM APIC V10.0.5 and DataPower Version 10.5.0.7. My setup involves utilizing the v5c DataPower gateway, for which I have obtained the v5c policy from the GitHub repository and imported it into the gateway service within my specific catalogue.

    My current challenge lies in using the PS512 algorithm to sign the JSON, requiring a private key. Although I have successfully imported the private key into DataPower, I am uncertain about how to reference this file within the policy. I would greatly appreciate any guidance on how to accomplish this.

    I have created the Key Object("private-key") in DataPower for the signing JSON and the Certificate object("Public-certificate") for the JSON verification.

    Thank you.



    ------------------------------
    Vishal Ghadage
    ------------------------------


  • 2.  RE: User Defined Policy - JWS | Crypto Object Reference understanding required

    Posted 10 hours ago

    Hi Vishal,
    We just completed a webex meeting on this, but I would like to document an answer this for the larger community.  This policy is from the v5 user defined policies sample user defined policies available at https://github.com/ibm-apiconnect/policy , and not that there is an analogous v10 API Gateway located at https://github.com/ibm-apiconnect/policy-apigw/tree/master/user-defined-policies .  These are sample policies, meant to be used as a starting point for those needing this functionality.  As you noted in the v5 policies, which you require for your v5 compatible gateway, this policy was created in 2016 when DataPower support was at version 7.2.0 :-) The readme indicates that only six algorithms were supported at that time, and today there are significantly more supported.  You can see this list of supported algorithms in the APIGW version, and you properly updated the yaml and hopefully the JSON schema to specify these updated types for the algorithm dropdown.

    As for the crypto object, this is an entry field that the sample expects a DataPower object name.  An orphaned Crypto Key or Certificate object and their associated files are not managed independently by the API Manager, thus the readme indicates that it is your responsibility to deploy those object and files directly to the DataPower instances that support your v5c gateway.  The question is how do you do that, especially in lieu that some algorithms require a private key or shared secret which you would want to have as secure as possible, ie, you don't want anyone that doesn't have permissions to see these private files by somehow seeing them in a deployment artifact.

    Typically v5c customer files and DataPower objects are deployed using a Gateway Extension.  In v5c's case, the extension's export.xml file would contain the DataPower object for the certificate, private key, or shared secret objects which would reference a file that is in the cert directory of the file system.  Since files have a hash in the files element of the export.xml file,  the best advice would be to place a temporary copy of these files in a local directory and do an export all files.  You'll then have the proper files entry  in that export except of course the directory needs to be changed to cert instead of local.  The zip file itself would need to have a cert folder added to it, and these files added into that directory.   With that in place, the Gateway Extension  should deploy the file and DataPower object, named which ever name you provided, and it is that name that would be specified as the Crypto Object.  Having said all of that, my security concern is that you have a private key or shared secret that the Gateway  Extension creator has to have access to, and whoever has access to the Gateway Extension.zip file has access to private information.

    Another option is to create a SOMA xml SOAP request to upload the file and create the DataPower object. That will need to be pushed by your own script every time a new DataPower is spun up.  If on a virtual/physical appliances, that may need to be done only once when a gateway appliance is initially created, but for a kubernetes  environment, perhaps a config map would get this deployed every time a DataPower pod is started.  Note the access to the private information  is still present.

    Finally another option you can try.  The UDP sample GatewayScript code is using the jose.createJWSHeader function, see https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=messages-josecreatejwsheader, which by specifying a String for the key the function assumes the string has a DataPower object name.  You could populate a Buffer object with the actual file information itself.   Perhaps if this file is located on a secure web server, the code could do a urlopen.open to read the file, do   a readAsBuffer on the response to get the response in a Buffer, and then the function would operate without the need for a DataPower object or file on the filesystem.  If you take that approach, check the webapi XML Manager's document cache policy to ensure those files are cached so you don't hammer the web server with unnecessary requests.

    Regards,
    Steve Linn



    ------------------------------
    Steve Linn
    Senior Consulting I/T Specialist
    IBM
    ------------------------------