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 muralidaran.shanmugham2and 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.
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.
As you can see below, the Link Account option is now enabled.
Before the skill can be enabled the user needs to authenticate themselves with SAP HCP Idm and then authorise Alexa to use the resource.
And if the user decides to authorise Alexa to access SAP resources they get the confirmation screen
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.
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
- SAP Managed Tags:
3 Comments
