Skip to Content

In this blog I would like to discuss some aspects concerning securing an Amazon Echo device using the Alexa voice service and SAP HCP.

Let me set the scene – you are creating a voice interface using an Amazon Echo device.  For now you want the sales team to use the Echo device to retrieve customer information from Hybris C4C, maybe list customers and then get some internal order (budget/expense) information from SAP S/4Hana.

Acknowledgement

Thank you to Murali Shanmugham and Nash Gajic from SAP APJ pre-sales for providing the Amazon Echo device.


Introduction

What are your options regarding securing the Echo device?  How do you identify the current user? 

The Echo device cannot be locked like your laptop, e.g. Windows username/password. Neither does it have the ability to authenticate a user with voice biometrics.  So unless you put it away and lock it up, anyone with access to it can interact with it.  In general it would be impractical to stow it away after use.  This has to be a consideration when having a voice capable device sitting on your desk that can access backend services, e.g. SAP business applications, and retrieve sensitive information.

For my use case I considered the backend business services that Alexa has access to.  In my use case I expose read only services.  Additionally I don’t expose strictly confidential information.  The impact of an unauthorised person using the device to retrieve information is relatively low.  But if I exposed write services it would have been all together different.

Now you have a few options to secure the solution.  The first is to use OAuth so the service consumer has to have a valid account when installing the Alexa skill.  Both Alexa and SAP HCP supports OAuth.  For authentication I added another security mechanism by creating the passphrase service.  This is a custom java application running on SAP HCP that stores user provided phrases for a limited amount of time.  On first usage Alexa prompts the user to provide a passphrase.  On subsequent interaction the status of the passphrase is checked for expiration.  If it has expired the user is prompted to authenticate again by providing the correct passphrase.

The passphrase service is secured with OAuth as well.  If the administrator revokes the OAuth access token for that user, the passphrase service fails to authenticate.

What I’m getting at is that you have to decide what the risks are and take appropriate measures.

OTP

If I wanted more security I could have opted for using an one time pin (OTP).  For example every time I use the device I have to verbally provide a generated OTP (delivered to my mobile?) to authenticate.  But this is where the interaction model breaks down in my opinion.  If I am using a voice enabled device why would I want to read an OTP from my mobile phone/web browser?  It would not only be inconvenient but also dilute the value of having a voice enabled device.  Maybe it would be better to use traditional user input at that point until voice biometrics become available.  Just my thoughts, let me know what you think.

Ok, so in the rest of this blog I’ll just go over what I’ve done and how I have done it.

Landscape overview

In retrospect making use of the Gatekeeper pattern might have been more elegant; although the underlying security concern would still be present.

Alexa deployment diagram.png

HCP OAuth – Alexa account linking

Lets link the Alexa skill with HCP using oauth.  In the Alexa skill kit developer editor enable account linking.  The authorisation and access token uri comes from HCP oauth settings page.

/wp-content/uploads/2016/09/a3_992190.png

As you can see below, the Link Account option is now enabled.

/wp-content/uploads/2016/09/a1_992189.png

Before the skill can be enabled the user needs to authenticate themselves with SAP HCP Idm and then authorise Alexa to use the resource.

/wp-content/uploads/2016/09/sso_996498.png

/wp-content/uploads/2016/09/o1_992192.png

And if the user decides to authorise Alexa to access SAP resources they get the confirmation screen

/wp-content/uploads/2016/09/a4_992194.png

Congratulations.  Your have now linked your Alexa skill with a SAP account.  This ensures that we now know the user accessing our secret passphrase service does have a valid SAP account.  See below for a short video.

HCP Passphrase service

The passphrase service is a custom java application running on HCP.  It stores a users secret passphrase and can subsequently authenticate a user based on the provided passphrase.  You can have a look at the code.  I’m using Spring boot and there is nothing fancy about it. Code on GitHub

Remember to create an OAuth scope.

/wp-content/uploads/2016/09/j1_992197.png

Most of the magic happens in the web.xml.  Again this is standard security configuration.


<filter>
  <display-name>OAuth scope definition for invoking a service</display-name>
  <filter-name>OAuthSecretScopeFilter</filter-name>
  <filter-class>com.sap.cloud.security.oauth2.OAuthAuthorizationFilter</filter-class>
  <init-param>
  <param-name>scope</param-name>
  <param-value>secret_store</param-value>
  </init-param>
  <init-param>
  <param-name>http-method</param-name>
  <param-value>get post</param-value>
  </init-param>
  </filter>
  <filter-mapping>
  <filter-name>OAuthSecretScopeFilter</filter-name>
  <url-pattern>/</url-pattern>
  </filter-mapping>
  <login-config>
  <auth-method>OAUTH</auth-method>
  </login-config>
  <security-constraint>
  <web-resource-collection>
  <web-resource-name>Protected Area</web-resource-name>
  <url-pattern>/</url-pattern>
  </web-resource-collection>
  <auth-constraint>
  <!-- Role Everyone will not be assignable -->
  <role-name>Everyone</role-name>
  </auth-constraint>
  </security-constraint>
  <security-role>
  <description>All SAP HANA Cloud Platform users</description>
  <role-name>Everyone</role-name>
  </security-role>

And that is it.  Below is a video showing the final product.

Conclusion

Making use of the available Alexa account linking and HCP oauth services it is possible to easily secure SAP business services.  You can also implement additional security if required based on the requirements you are presented with.  But I hope I have made a case that you should also consider what is appropriate and sensible when using such a device.

Thank you for reading and enjoy your HCP journey.  Cheers from a sunny (but cold) Melbourne.

Nic

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Frank Koehntopp

    Quite cool 😉

    Of course your threat model excludes the elephant in the room, which is sending sensitive data like your credentials and customer data through Amazon…

    (0) 
    1. Nic Botha Post author

      Good points. Securing credentials can be achieved as mentioned by implementing something like the gatekeeper pattern..

      Sending potentially sensitive data though Amazon (or any other service provider)..yes, another discussion 🙂 .

      (0) 
  2. Markus Wilhelm

    Hi Nic,

    we try to reproduce the described on our HCP but we struggle with the HCP Passphrase service. What we did so far: downloaded GIT source and added to an eclipse project. Created a war extract and uploaded to HCP. Started the java application but when calling the URL I receive an error 401.

    Can you provide a more detailed explanation of how to cionfigure and handle this?

    BR Markus

     

    (0) 

Leave a Reply