Skip to main content

I’m trying to setup a connection between my application and the simple notification service (SNS) from AWS. This is proving to be troublesome because of the way AWS manages these subscriptions.

To subscribe AWS first sends a subscription token to the endpoint (in indicium)  that will receive the SNS notifications. The endpoint in my application then needs to reply with the SNS-token to verify the subscription.

To send the subscription token, AWS sends two messages: One without authentication and then one with authentication based on the header that is received in response of the first message.

The endpoint in my application needs to respond to the first message without authentication with a 401 code with a header that specifies the type of authentication that is expected*: 

WWW-Authenticate: Basic realm=“<application>” .

Indicium automatically responds with a 401 code and the header:

WWW-Authenticate: Indicium realm=“<application>”

 

Even when using a message protocol-independent web service I haven’t been able to manipulate the headers attached to authentication. Is there a way to manage this anyway and make indicium compatible with AWS SNS?

 

* https://maxbeatty.com/2015/11/16/how-to-subscribe-to-aws-sns-using-https-with-basic-authentication/

This is a very tricky issue. It is unfortunate that you cannot force AWS SNS to pre-emptively provide basic credentials for the subscription.

You can try to intercept/log the subscription message before it reaches Indicium somehow and manually activate the subscription with a browser via the SubscribeURL in this message. More info on the manual activation here.

Alternatively, you could create an override when a request has the User-Agent: Amazon Simple Notification Service Agent. The 401 response should set or overwrite the WWW-Authenticate header to Basic realm=Indicium. This might be possible when the requests are routed via the API gateway. More info here.

In the meanwhile we can look into changing Indicium to support this scenario. It must be noted that it is far from ideal to have very specific exceptions like this in the authentication code of Indicium.

Please keep us posted on the progress.

Note that the messages sent by AWS SNS use content-type text/plain instead of application/json.

This is a known issue that has been around for almost a decade now.

This prevents use of the regular OData API and requires the use of message-protocol independent web services.

If a rewrite rule is created in the gateway for this user agent, it could also correct the content type. This will most likely allow the use of regular OData services, such as a task, to receive the message.

@Anne Buit we are familiar with your suggestions and the AWS issue. It is now (temporarily) resolved with a Lambda between SNS and Indicium.
 

Thanks to your earlier suggestion and extensive blogs we actually got the idea to circumvent the Content Type issue with the message-protocol independent web services and got that part covered. Then we unfortunately got stuck at the Subscription confirmation part…

 

Ideally, we want to get rid of the Lambda (or API Gateway proxy) in between. Thinkwise and AWS SNS should be able to work together, given the fact that SNS is such a common service (yeah, I know AWS sucks on both the Content Type bug and the way they handle Subscription confirmation, but they are the bigger ones and I guess it’s easier to get flexibility in your low code platform...). 
 

How about adding some flexibility on authentication responses, specifically for message-protocol independent web services in Indicium?

A lambda between SNS and Indicium will indeed allow for a similar solution.

Message protocol independent web services cannot take responsibility of authentication by design, because they are subject to authorization as defined in the Intelligent Application Manager.

You’d need access to the service to execute it and handle your authentication. But only after being authenticated you’d be able to access the service. This is a catch-22.

As mentioned before, I’ll raise this issue with the team and see if we can introduce some (hard-coded) authentication challenge exceptions for specific user agents.

As mentioned before, I’ll raise this issue with the team and see if we can introduce some (hard-coded) authentication challenge exceptions for specific user agents.

@Anne Buit What's the status regarding a fix for being able to directly subscribe Indicium to AWS SNS? Would it help to have a TCP raised for this?

We believe that the root cause of this problem lies with AWS. However, it is highly unlikely that we can strong-arm them into resolving this problem.

With great reluctance we have decided to resolve this by implementing a hard-coded exception for the user agent used by Amazon SNS, challenging them to use basic authentication on a 401 response.

We’ll post an update in this topic when an Indicium version containing the solution has been released.

The basic authentication challenge for AWS SNS has been added in the 2022.1.11 release of Indicium:

 

Reply


Terms & ConditionsCookie settings