When reviewing the xml detail of an existing IDP; a Federated IDP for example, there is no indication of what is needed to populate the IDP with a certificate that has been previously imported to Policy Manager ( or using Restman for that matter). This kb article serves the use case with a basic example:
This kb assumes:
RESTMAN Policy is installed and authentication is working.
RESTMAN Service Properties has the HTTP/FTP defaults enabled. (POST, GET, PUT, DELETE)
API Gateway: Any
RESTMAN Policy installed
SOAP UI or similar for testing
RESTMAN doc reference;
Trusted Certificates: https://Gateway-host-name:port/restman/1.0/doc/restDoc.html#1.0/trustedCertificates
Identity Providers: https://Gateway-host-name:port/restman/1.0/doc/restDoc.html#1.0/identityProviders
- To start, retrieve the xml of an existing certificate intended to be used for the FIP using a GET request to /trustedCertificates
You will need the id of the certificate to be used in the PUT body for the FIP. Note that the id's in the example have been strikethrough to indicate they are to be replaced in your environment.
- Next you will need the basic framework of the FIP xml that will be used to update it with the trusted certificate reference id;
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<l7:IdentityProvider xmlns:l7="http://ns.l7tech.com/2010/04/gateway-management" id="
The section in bold face is the addition of the certificate reference back to /trustedCertificates
You do not have to include the version tag on line 2. It is purely for version control. Just make sure the version you specify is not lower than the current version of the FIP from the GET request.
Obviously you will replace the id strings with strings from your actual Gateway db.
- You can now call PUT to the specific IDP at example: /identityProviders/
The raw output should be:
HTTP/1.1 200 OK
You can then follow up with a new GET request to /identityProviders/
9e22f6337382eb7fe85579c60cf8d5a6 to verify the certificate reference has been added.