CORS preflight on REST service with HTTP basic authentication enabled

[anselmopeixoto]

I have a REST service with basic HTTP authentication enabled and I want to access it from the browser (I tried using javascript XMLHttpRequest), but when I send a GET to the resource setting the authorization header it does first a preflight request with an OPTIONS verb that waits for a response with the header "Access-Control-Allow-Headers"  (among others) containing "Authorization" as one of the headers allowed for the GET verb.

I saw https://community.talend.com/t5/Design-and-Development/REST-interface-POST-and-CORS/td-p/65638 on previous talend forum suggesting to implement an OPTIONS verb with the same URI as GET and with these headers in the response. I have tested it successfully with basic HTTP authentication disabled (I simulated setting a different header on GET verb since authentication was disabled and it also sent the OPTIONS preflight). However, when I enable HTTP authentication again it is also applied to the OPTIONS verb and the authorization header is required for OPTIONS verb also, driving into a HTTP 401 Unauthorized error.

There is this JIRA ticket already opened for implementing CORS on tRestRequest. Is it related to this issue?

If so and while it is not solved, Is there any known workaround to access from the browser a REST service with HTTP authentication enabled?

Thanks in advance.

Best regards,

Anselmo

[Anonymous]

Hello,

This jira issue https://jira.talendforge.org/browse/TESB-17678 is about cross-origin resource sharing. During the pre-flight (OPTIONS) the browser is not using authentication.

This issue is still in process and we will keep you posted.

Best regards

Sabrina

[Anonymous]

Just to add some context - and add a BIG YES VOTE for this enhancement request...

The W3 spec for CORS preflight requests states that user credentials should be excluded, so this enhancement would make Talend more compliant. This is important because REST APIs are more commonly used as an abstract layer for the Microservice architecture (cross origin situations) and development team who use the tRESTRequest component need to account for this situation.

Workaround

1. turn off the authentication in the tRESTRequest
2. Add Authorization to the "non OPTIONS" Output Flow (e.g.: postData) as a header parameter.
3. In the "postData" flow, add a  tJavaRow component that decodes (Base64) and splits (colon) the Authorization parameter in to the username and password
4. Follow the flow with a tSOAP component to call the STS service
5. Next, add a tExtractXMLField to extract the Assertion in the response.
   1. Loop XPath query = "/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='RequestSecurityTokenResponseCollection']/*[local-name()='RequestSecurityTokenResponse']/*[local-name()='RequestedSecurityToken']"
   2. assertion = "*[local-name()='Assertion']"
   3. userId="*[local-name()='Assertion']/*[local-name()='Subject']/*[local-name()='NameID']"
6. If the username in step #3 equals the userId in step #5.3, then authentication is successful
7. Extra - add a tJavaRow to deflate and encode Base64 the assertion (don't forget to remove all the tabs and carriage returns) - This is the SAML token that you can pass in the tRESTResponse in the head to be used for SAML authentication.

Note: This work around is good for wrapping the STS authentication service into a RESTful endpoint to support Single Sign-On (using SAML)

Reference

Here are links to other discussions about this same requirement

• https://community.talend.com/t5/Design-and-Development/Talend-ESB-Runtime-and-CORS/td-p/59166
  https://jira.talendforge.org/browse/TESB-17678
  https://community.talend.com/t5/Design-and-Development/REST-interface-POST-and-CORS/td-p/65638
  https://community.talend.com/t5/Design-and-Development/CORS-preflight-on-REST-service-with-HTTP-basi...