Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: 2/3/2022 10:02:00 AM
From: Jan Lindstam
Subject: RE: ICAP scanning based on http request headers

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Hi, 

thanks for clarification. Would you have possibility to give guidance on what the xlt transformation rule would change eg how do we modify the object name? Are any of these modifying object name? https://github.com/IBM-Security/isam-support/tree/master/config-example/webseal/http-transformations/request

Best regards

------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: Thu February 03, 2022 02:48 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

I just want to be 100% clear that based on my suggestion you would only need a different path in the object space, which is used for authorization decisions only.  The URL would remain the same.  However, I understand that changing the path in the back-end could be a simpler approach for you.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
 

 

 

Original Message:
Sent: 2/3/2022 10:02:00 AM
From: Jan Lindstam
Subject: RE: ICAP scanning based on http request headers

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Hi Jan,

The rule https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/http-transformations/request/request-modify-uri.xslt is a simple example of how to modify the URI.  It is a simple find and replace.  The rule https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/http-transformations/request/request-modify-uri-based-on-referrer.xslt is more complex and modifies the URI based on the value of a header.  In this example it is the referrer header but should be easy enough to change the rule to base it off the content-type header.

------------------------------
Nick
IBM Security Verify Customer Support
------------------------------

Original Message:
Sent: Fri February 04, 2022 05:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi, 

thanks for clarification. Would you have possibility to give guidance on what the xlt transformation rule would change eg how do we modify the object name? Are any of these modifying object name? https://github.com/IBM-Security/isam-support/tree/master/config-example/webseal/http-transformations/request

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Thu February 03, 2022 02:48 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

I just want to be 100% clear that based on my suggestion you would only need a different path in the object space, which is used for authorization decisions only.  The URL would remain the same.  However, I understand that changing the path in the back-end could be a simpler approach for you.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
 

 

 

Original Message:
Sent: 2/3/2022 10:02:00 AM
From: Jan Lindstam
Subject: RE: ICAP scanning based on http request headers

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Jan,

My previous reply was for changing the URI, not the object.  A simple example for changing the object is:

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:external="http://xsltfunctions.isam.ibm.com" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:strip-space elements="*"/>
<xsl:template match="/">
<HTTPRequestChange>
<ObjectName>/WebSEAL/instance/send-to-icap</ObjectName>
</HTTPRequestChange>
</xsl:template>
</xsl:stylesheet>

Based on value of content-type conditionally set ObjectName.

------------------------------
Nick
IBM Security Verify Customer Support
------------------------------

Original Message:
Sent: Fri February 04, 2022 05:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi, 

thanks for clarification. Would you have possibility to give guidance on what the xlt transformation rule would change eg how do we modify the object name? Are any of these modifying object name? https://github.com/IBM-Security/isam-support/tree/master/config-example/webseal/http-transformations/request

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Thu February 03, 2022 02:48 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

I just want to be 100% clear that based on my suggestion you would only need a different path in the object space, which is used for authorization decisions only.  The URL would remain the same.  However, I understand that changing the path in the back-end could be a simpler approach for you.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
 

 

 

Original Message:
Sent: 2/3/2022 10:02:00 AM
From: Jan Lindstam
Subject: RE: ICAP scanning based on http request headers

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------

Big thanks Nick,

we'll try these.

Best regards.

------------------------------
Jan Lindstam
------------------------------

Original Message:
Sent: Mon February 07, 2022 01:52 PM
From: Nick Lloyd
Subject: ICAP scanning based on http request headers

Jan,

My previous reply was for changing the URI, not the object.  A simple example for changing the object is:

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:external="http://xsltfunctions.isam.ibm.com" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:strip-space elements="*"/>
<xsl:template match="/">
<HTTPRequestChange>
<ObjectName>/WebSEAL/instance/send-to-icap</ObjectName>
</HTTPRequestChange>
</xsl:template>
</xsl:stylesheet>

Based on value of content-type conditionally set ObjectName.

------------------------------
Nick
IBM Security Verify Customer Support

Original Message:
Sent: Fri February 04, 2022 05:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi, 

thanks for clarification. Would you have possibility to give guidance on what the xlt transformation rule would change eg how do we modify the object name? Are any of these modifying object name? https://github.com/IBM-Security/isam-support/tree/master/config-example/webseal/http-transformations/request

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Thu February 03, 2022 02:48 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

I just want to be 100% clear that based on my suggestion you would only need a different path in the object space, which is used for authorization decisions only.  The URL would remain the same.  However, I understand that changing the path in the back-end could be a simpler approach for you.

 

I hope that this helps.

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
 

 

 

Original Message:
Sent: 2/3/2022 10:02:00 AM
From: Jan Lindstam
Subject: RE: ICAP scanning based on http request headers

Hi Scott,  

thank you for response!  Our case is such that the backend app currently has just one path from where everything is served. Based on above we understood that there would actually need to be different path available to accomplish header-based routing. In the end, we'll likely consider changing the backend app to serve attachments from a path which is distinguishable and solely used for upload - that being tied to ICAP POP.

Best regards

------------------------------
Jan Lindstam

Original Message:
Sent: Wed February 02, 2022 03:07 PM
From: Scott Exton
Subject: ICAP scanning based on http request headers

Jan,

 

ICAP processing is conditional, based on a POP which needs to be attached to the object name which is referenced in the authorization decision. 

 

Your only option would be to use a HTTP transformation rule to change the object name which is used in the authorization decision, when the multipart content-type header is present, to one which has the ICAP POP associated with it.  This should give you the flexibility which you need.

 

I hope that this helps.

 

 

Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor

 

 

 

Original Message:
Sent: 2/2/2022 11:21:00 AM
From: Jan Lindstam
Subject: ICAP scanning based on http request headers

Hi,

we are investigating possibilities to configure ICAP with Webseals, basically for virus-scanning incoming files.  The documentation https://www.ibm.com/docs/en/sva/10.0.2?topic=support-icap-integration-reverse-proxy-workflow  shows how to configure the connection. 

Question is this: Is there possiblity to limit the calls to ICAP to only cases where HTTP request would actually contain headers indicating file upload, eg something like Content-type header containing  multipart ?  Reason for this would be that we would not want all the traffic to the backend app to do roundtrip to ICAP.

Best Regards




------------------------------
Jan Lindstam
------------------------------