Aws-cdk: cognito user pools - support SES integration

[nija-at]

AWS Docs to the feature: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-email.html#user-pool-email-developer

CloudFormation properties: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cognito-userpool-emailconfiguration.html

---

This is a :rocket: Feature Request

[rehanvdm]

+1

[tom139]

Hi, I did some research I would like to share:
There are 3 possible sender configuration:

• __default__ emails are sent from [email protected]_ and there is the ability to set the replyTo property only;
• __Cognito__ sender: this allow to specify a custom sender address (via a verified identity in SES) and set the from field (with both email and name);
• __SES__ sender: this has the same properties as the above cognito sender plus the ability to set a _ConfigurationSet_ to better track sent emails.

The default should be initiable with empty props:

let sender = new DefaultSender({
  replyTo?: "replyToAddress",
});

If the user wish to use cognito must specify all required fields

let emailSender = new CognitoSender({
  from: {
    email: "[email protected]",
    name: "Test Address",
  },
  replyTo: "[email protected]"
  sourceArn: "arn for source"
});

Finally, if the user wants to use SES the user can specify the optional _configurationSet_ property.

let emailSender = new SESSender({
  configurationSet?: "String"
  from: {
    email: "[email protected]",
    name: "Test Address",
  },
  replyTo: "[email protected]"
  sourceArn: "arn for source"
});

As you can see I propose to split the _From_ property in two, allowing better check of correctness (and helping the user understand how to use the field.

/**
 * Represents the From field.
 * If only email is set the output value should be the email address, otherwise
 * the outcome should be `name <email>` (i.e. Test User `<[email protected]>`)
 */
export interface FromEmailAddress {
    /**
     * The email for the From field.
     *
     * @example [email protected]
     */
    readonly email: string

    /**
     * The optional sender's name
     *
     * @example Test User
     */
    readonly name?: string
}

To Do

• [ ] check if some role is created and if cdk should perform some operation (e.g. to allow Cognito to use the identity specified in SourceArn);
• [ ] check if some SES resource could be used to auto populate some fields in Cognito and SES senders:
  
  
  
  • CfnConfigurationSet could be accepted in the _configurationSet_ property
  
  

---

I will start working soon on a PR.

[asterikx]

~Is it possible to import/lookup the sourceArn of a verified email address by its name, e.g. [email protected]?~

Edit: Since the ARN has always the structure arn:aws:ses:${this.region}:${this.account}:identity/${fromEmail}, there is no need to look it up.

Ideally, it should be possible to specify any "from" email, and, if unverified, cdk deploy triggers verification and blocks until the user has received and confirmed the verification email (similarly to the DnsCertificate construct).

[rinde]

Is there a reason why this issue is not marked as required for graduation in this overview? According to the Cognito limits that come with the default settings, maximum 50 emails can be sent per day, severely limiting the number of people that can use my service. Therefore, I think this is an important feature to have in the CDK.

Is there currently a workaround for a UserPool that is configured using the CDK high level constructs to enable email sending via SES? Or is the only way to rewrite my stack using the lower level CloudFormation constructs for UserPool?

[asterikx]

@rinde The workaround is quite easy.

Just change the emailConfiguration by modifying the CFN resource encapsulated by the CDK UserPool construct (see CDK Developer Guide here):

const cfnUserPool = userPool.node.defaultChild as cognito.CfnUserPool;

cfnUserPool.emailConfiguration = {
  emailSendingAccount: 'DEVELOPER',
  from: `Someone from MyService <${fromEmailAddress}>`,
  sourceArn: `arn:aws:ses:eu-west-1:${this.account}:identity/${fromEmailAddress}`, // SES integration is only available in us-east-1, us-west-2, eu-west-1
};

I agree that these SES configurations should be added to the CDK construct since almost every customer-facing app requires SES instead of Cognito's built-in email capabilities.

Note that the sending email address (fromEmailAddress above) must be verified in SES (see SES Developer Guide) and the SES account must be moved out of the SES Sandbox to send emails to unverified email addresses (your customers). See the SES Developer Guide here and here for more details.

[gregorypierce]

I'd specifically like Pinpoint integration. If I've already got a Pinpoint app, I already have a MANAGED mechanism to send emails, texts, etc. I wouldn't want to create a new channel to support Cognito "just because".

[nija-at]

As far as I can tell, Pinpoint is an analytics system. This issue is regarding sending emails and integrating SES with user pools. Please open a separate issue, if you're interested in a different feature.

[gregorypierce]

I'll open a different issue, but Pinpoint isn't (specifically) an analytics system. It's an aggregation of all the messaging channels for SMS, Voice, Email, Push Notifications, Messaging campaigns, etc. It's closer to Mailchimp than it is anything specifically related to analytics.

[apoorvmote]

Is there any workaround for adding custom cloudformation include for ses support?

I was learning cloudformation but when I found out about CDK then I abandoned cloudformation and completely forgot everything I learned about cloudformation. I am actually looking for excuse to actually finish learning cloudformation.

But if I learned cloudformation then can I fill gaps of CDK? or I cannot override CDK code with custom cloudformation?