Amazon Simple Notification Service

Amazon has just come out with yet another service to help build your app on AWS. Their Simple Notification Service is a pub/sub setup where you create topics and users can subscribe. Delivery is via a “push” mechanism, so subscribers won’t need to poll for new messages. Output can be one of several protocols which include http/https/email/email-json or sqs. While the e-mail output can be useful for managing things like users watching a comment or blog post. The other options are clearly geared towards consumption by other software. Imagine the http options being used to implement a web service callback. SQS is clearly helpful for building loosely coupled services in the cloud. Now, SNS can help feed into those services.

SNS overview

For more information, visit the SNS documentation
Jeff Barr also does an excellent job of describing SNS at the AWS blog.

typica now supports SNS. Subversion contains the latest code. A release will be coming shortly. (check this space for updates)

Here’s an example of how to use typica to create a topic, subscribe, send a message, then unsubscribe and remove the topic;

NotificationService sns = new NotificationService(props.getProperty("aws.accessId"), props.getProperty("aws.secretKey"));
Result<String> ret = sns.createTopic("TestTopic");
String topicArn = ret.getResult();
System.err.println("topicArn: "+topicArn);

sns.subscribe(topicArn, "email", "dkavanagh@gmail.com");
System.out.println("Waiting till subscription is confirmed.");
System.out.println("Check your e-mail, confirm, then press <return>");
System.in.read();

List<SubscriptionInfo> subs = sns.listSubscriptionsByTopic(topicArn, null).getItems();
String subArn = subs.get(0).getSubscriptionArn();
System.err.println("subscriptionArn: "+subArn);
sns.publish(topicArn, TEST_MSG, "[SNS] testing...");

sns.unsubscribe(subArn);
sns.deleteTopic(topicArn);

Creating your own AccessId and SecretKey

When building your own web services, security has to be one of the concerns. Having worked with Amazon Web Services extensively over he past several years, I’ve become quite familiar with the Query API security features. I wrote a java client for many of their services, so the workings of the various signing methods needed to be understood.
On a recent project, I decided to implement the same version 2 signing that Amazon uses on most of their web services. I thought I’d be able to leverage my typica client code, and the signing code to help validate requests on the server side. Before any of this could happen, I needed to have a way to generate my own access id and secret key. Shown below is some code that I came up with (using some Eucalyptus code as a reference).

public class Credentials {
	static {
		Security.addProvider( new BouncyCastleProvider( ) );
	}

	public static String genAccessId(String userName) {
		try {
			byte[] userBytes = userName.getBytes();
			MessageDigest digest = MessageDigest.getInstance("SHA224", "BC");
			digest.update(userBytes);
			byte [] digestBytes = digest.digest();
			return new String(Base64.encodeBase64(digestBytes)).replaceAll( "\\p{Punct}", "" ).substring(0, 20);
		} catch (Exception ex) {	// catch those security exceptions
			System.err.println("Error with provider : "+ex.getMessage());
			System.exit(-2);
		}
		return null;
	}

	public static String genSecretKey(String userName) {
		try {
			byte[] userBytes = userName.getBytes();
			MessageDigest digest = MessageDigest.getInstance("SHA256", "BC");
			digest.update(userBytes);
			SecureRandom random = new SecureRandom();
			random.setSeed(System.currentTimeMillis());
			byte[] randomBytes = random.generateSeed(userBytes.length);
			digest.update(randomBytes);
			byte [] digestBytes = digest.digest();
			return new String(Base64.encodeBase64(digestBytes)).substring(0, 40);
		} catch (Exception ex) {	// catch those security exceptions
			System.err.println("Error with provider : "+ex.getMessage());
			System.exit(-2);
		}
		return null;
	}
}

When creating a user on the server, I generate an access id and secret key based on the username. A new secret key can be generated at any time, using that username. The access id shouldn’t be changed (as a rule).