IDM 4.6 work flow REST action - how to retrieve response headers?

[Anonymous_User]

Hi All,

Anyone knows of a way to retrieve the header of the response message
with the REST action? Need to reuse the same token in multiple calls due
to the REST API we are integrating to and cannot find a way to do so
from the workflow.

Cheers,

-Fernando

[Anonymous_User]

On 7/23/2018 3:44 PM, Fernando Freitas wrote:
> Hi All,
>
> Anyone knows of a way to retrieve the header of the response message
> with the REST action? Need to reuse the same token in multiple calls due
> to the REST API we are integrating to and cannot find a way to do so
> from the workflow.
>
> Cheers,
>
> -Fernando

dang no replies...

Ended up using the http commons 3.1 that comes inside IDMProv to code my
own quick n simple httpget piece to reach the header information, and
calling it from mapping activity. Code for future reference:

https://github.com/fchierad/PRD/blob/master/other/httpreq.js

[cpedersen]

On 25.07.18 04:00, Fernando Freitas wrote:
> On 7/23/2018 3:44 PM, Fernando Freitas wrote:
>> Hi All,
>>
>> Anyone knows of a way to retrieve the header of the response message
>> with the REST action? Need to reuse the same token in multiple calls
>> due to the REST API we are integrating to and cannot find a way to do
>> so from the workflow.
>>
>> Cheers,
>>
>> -Fernando
>
> dang no replies...
>
> Ended up using the http commons 3.1 that comes inside IDMProv to code my
> own quick n simple httpget piece to reach the header information, and
> calling it from mapping activity. Code for future reference:
>
> https://github.com/fchierad/PRD/blob/master/other/httpreq.js

Nice, does it also handle https, and selfsigned certificates?

Thanks,
Casper

[Anonymous_User]

On 7/25/2018 2:43 AM, Casper Pedersen wrote:
> On 25.07.18 04:00, Fernando Freitas wrote:
>> On 7/23/2018 3:44 PM, Fernando Freitas wrote:
>>> Hi All,
>>>
>>> Anyone knows of a way to retrieve the header of the response message
>>> with the REST action? Need to reuse the same token in multiple calls
>>> due to the REST API we are integrating to and cannot find a way to do
>>> so from the workflow.
>>>
>>> Cheers,
>>>
>>> -Fernando
>>
>> dang no replies...
>>
>> Ended up using the http commons 3.1 that comes inside IDMProv to code
>> my own quick n simple httpget piece to reach the header information,
>> and calling it from mapping activity. Code for future reference:
>>
>> https://github.com/fchierad/PRD/blob/master/other/httpreq.js
>
> Nice, does it also handle https, and selfsigned certificates?
>
> Thanks,
> Casper
It handles https. Have not tested self signed, will do so later tonight.

[ScorpionSting]

Fernando Freitas;2484737 wrote:
On 7/25/2018 2:43 AM, Casper Pedersen wrote:
> On 25.07.18 04:00, Fernando Freitas wrote:
>> On 7/23/2018 3:44 PM, Fernando Freitas wrote:
>>> Hi All,
>>>
>>> Anyone knows of a way to retrieve the header of the response message
>>> with the REST action? Need to reuse the same token in multiple calls
>>> due to the REST API we are integrating to and cannot find a way to do
>>> so from the workflow.
>>>
>>> Cheers,
>>>
>>> -Fernando
>>
>> dang no replies...
>>
>> Ended up using the http commons 3.1 that comes inside IDMProv to code
>> my own quick n simple httpget piece to reach the header information,
>> and calling it from mapping activity. Code for future reference:
>>
>> https://github.com/fchierad/PRD/blob/master/other/httpreq.js
>
> Nice, does it also handle https, and selfsigned certificates?
>
> Thanks,
> Casper
It handles https. Have not tested self signed, will do so later tonight.

Self-signed will be pain, but if there is an internally signed cert you should be able to just import the CA into the jre/lib/security/cacerts as -trustcacerts and that would be inherited.

From what I've read, self-signed will require instantiating Protocol myhttps = new Protocol("https", new MySSLSocketFactory(), 443); and binding that to the connection.

[ffreitas]

Good tip. on IDM 4.5 and later (where I am testing the code/need it to run) we do have some native examples built for the REST activity, including one to trust all certs. Will prob tweak the code to use all 3 sample truststores and leave the trust all certs one as default. This code is only useful till MicroFocus enhance the REST activity to return the headers anyways 🙂

[ffreitas]

fun. https://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.html does NOT take another socket factory as a constructor parameter, and implementing one that is accepted by the Protocol() call requires something like:

public class EasySSLProtocolSocketFactory implements SecureProtocolSocketFactory {

to be used as a parameter there. Unfortunately I have not found a way to create that in ECMA making calls to Java 🙂 might be why the REST activity parameter takes a truststore call - it can then use the truststore in an internal implementation of the SecureProtocolSocketFactory ...

[cpedersen]

On 27.07.18 06:46, ffreitas wrote:
>
> fun.
> https://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.html
> does NOT take another socket factory as a constructor parameter, and
> implementing one that is accepted by the Protocol() call requires
> something like:
>
> public class EasySSLProtocolSocketFactory implements
> SecureProtocolSocketFactory {
>
> to be used as a parameter there. Unfortunately I have not found a way to
> create that in ECMA making calls to Java 🙂 might be why the REST
> activity parameter takes a truststore call - it can then use the
> truststore in an internal implementation of the
> SecureProtocolSocketFactory ...
>
>
After lots of trial and error, and even more copy/paste from many
examples this is what I ended up with. This will handle self-signed
certificates, but until Apache httpclient 4.4 - most of the code is
deprecated with httpclient 4.5 (still runs), might not work after 4.6.

This will build an HttpClient class which will talk to an end-point
which uses an selfsigned certificate.


Casper



@SuppressWarnings("deprecation")
private HttpClient buildClient() throws KeyManagementException,
NoSuchAlgorithmException, KeyStoreException {

HttpClientBuilder b = HttpClientBuilder.create();

// setup a Trust Strategy that allows all certificates.
//
SSLContext sslContext = new
SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() {
public boolean isTrusted(X509Certificate[] arg0,
String arg1) throws CertificateException {
return true;
}
}).build();

b.setSslcontext(sslContext);

// don't check Hostnames, either.
// -- use
SSLConnectionSocketFactory.getDefaultHostnameVerifier(), if
// you don't want to weaken
HostnameVerifier hostnameVerifier =
SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;

// here's the special part:
// -- need to create an SSL Socket Factory, to use our
weakened "trust
// strategy";
// -- and create a Registry, to register it.
//
SSLConnectionSocketFactory sslSocketFactory = new
SSLConnectionSocketFactory(sslContext, hostnameVerifier);
Registry<ConnectionSocketFactory> socketFactoryRegistry =
RegistryBuilder.<ConnectionSocketFactory>create()
.register("http",
PlainConnectionSocketFactory.getSocketFactory()).register("https",
sslSocketFactory)
.build();

// now, we create connection-manager using our Registry.
// -- allows multi-threaded use
PoolingHttpClientConnectionManager connMgr = new
PoolingHttpClientConnectionManager(socketFactoryRegistry);
b.setConnectionManager(connMgr);

// finally, build the HttpClient;
// -- done!
HttpClient client = b.build();
return client;
}

[Anonymous_User]

On 7/31/2018 7:18 AM, Casper Pedersen wrote:
> On 27.07.18 06:46, ffreitas wrote:
>>
>> fun.
>> https://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.html
>> does NOT take another socket factory as a constructor parameter, and
>> implementing one that is accepted by the Protocol() call requires
>> something like:
>>
>> public class EasySSLProtocolSocketFactory implements
>> SecureProtocolSocketFactory {
>>
>> to be used as a parameter there. Unfortunately I have not found a way to
>> create that in ECMA making calls to Java 🙂 might be why the REST
>> activity parameter takes a truststore call - it can then use the
>> truststore in an internal implementation of the
>> SecureProtocolSocketFactory ...
>>
>>
> After lots of trial and error, and even more copy/paste from many examples this is what I ended up with. This will handle self-signed certificates, but until Apache httpclient 4.4 - most of the code is deprecated with httpclient 4.5 (still runs), might not work after 4.6.
>
> This will build an HttpClient class which will talk to an end-point which uses an selfsigned certificate.
>
>
> Casper
>
>
>
>  @SuppressWarnings("deprecation")
>        private HttpClient buildClient() throws KeyManagementException, NoSuchAlgorithmException, KeyStoreException {
>
>              HttpClientBuilder b = HttpClientBuilder.create();
>
>              // setup a Trust Strategy that allows all certificates.
>              //
>              SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() {
>                     public boolean isTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
>                            return true;
>                     }
>              }).build();
>
>              b.setSslcontext(sslContext);
>
>              // don't check Hostnames, either.
>              // -- use SSLConnectionSocketFactory.getDefaultHostnameVerifier(), if
>              // you don't want to weaken
>              HostnameVerifier hostnameVerifier = SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;
>
>              // here's the special part:
>              // -- need to create an SSL Socket Factory, to use our weakened "trust
>              // strategy";
>              // -- and create a Registry, to register it.
>              //
>              SSLConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(sslContext, hostnameVerifier);
>              Registry<ConnectionSocketFactory> socketFactoryRegistry = RegistryBuilder.<ConnectionSocketFactory>create()
>                            .register("http", PlainConnectionSocketFactory.getSocketFactory()).register("https", sslSocketFactory)
>                            .build();
>
>              // now, we create connection-manager using our Registry.
>              // -- allows multi-threaded use
>              PoolingHttpClientConnectionManager connMgr = new PoolingHttpClientConnectionManager(socketFactoryRegistry);
>              b.setConnectionManager(connMgr);
>
>              // finally, build the HttpClient;
>              // -- done!
>              HttpClient client = b.build();
>              return client;
>        }
>
>
>

Thanks Casper

[cpedersen]

On 26.07.18 02:14, ScorpionSting wrote:
>
> Fernando Freitas;2484737 Wrote:
>> On 7/25/2018 2:43 AM, Casper Pedersen wrote:
>>> On 25.07.18 04:00, Fernando Freitas wrote:
>>>> On 7/23/2018 3:44 PM, Fernando Freitas wrote:
>>>>> Hi All,
>>>>>
>>>>> Anyone knows of a way to retrieve the header of the response message
>>>>> with the REST action? Need to reuse the same token in multiple calls
>>>>> due to the REST API we are integrating to and cannot find a way to
>> do
>>>>> so from the workflow.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -Fernando
>>>>
>>>> dang no replies...
>>>>
>>>> Ended up using the http commons 3.1 that comes inside IDMProv to code
>>>> my own quick n simple httpget piece to reach the header information,
>>>> and calling it from mapping activity. Code for future reference:
>>>>
>>>> https://github.com/fchierad/PRD/blob/master/other/httpreq.js
>>>
>>> Nice, does it also handle https, and selfsigned certificates?
>>>
>>> Thanks,
>>> Casper
>> It handles https. Have not tested self signed, will do so later tonight.
>
> Self-signed will be pain, but if there is an internally signed cert you
> should be able to just import the CA into the jre/lib/security/cacerts
> as -trustcacerts and that would be inherited.
>
> From what I've read, self-signed will require instantiating Protocol
> myhttps = new Protocol("https", new MySSLSocketFactory(), 443); and
> binding that to the connection.
>
>

Apache was so nice to change how they handle certificates with
httpcomponents-client-4.5.6 (onwards), handling self-signed certificates
(without import into cacerts) will/is a pain there after. They
deprecated a large part of the SSLContextBuilder and
SSLConnectionSocketFactory code 😞

If possible, stay on httpcomponents-client-4.4.

I agree, it's probably easier to import the public certificate than
implementing code to deal with self signed certificates from here on.


Casper