alan-turing-institute / alexa-room-finder Goto Github PK

Option 0 - not really an option

My original planned security model (to simplify testing during development) was this:

However, this was only intended for a test environment using a false account, and is very insecure for a live environment; anyone who can send a request to our Lambda function (which only requires knowing a non-secret ID), can read and write our calendars (though I suspect only in ways our function defines.) Here are a couple options for replacement:

Option 1

Alexa skills provides an in-app account-linking function, that allows you to link accounts to any service that uses OAuth. We can register an app that provides a token in Active Directory, and then pass that token to Lambda so it can use it to access the calendars.

The advantage of this over Option 0 is that it means that:

• our client secret is securely stored within Alexa skills, which has a place designed to do this.
• people who access our Lambda code would still need a token, so can't do anything.

The disadvantage is there may still be a security flaw; it applies to Option 2 as well so I addressed it below.

Option 2

I'd rather not do this because the "Lambda function" replacement uses ASP.NET instead of Node, and requires some nasty middleware. However, it demonstrates a somewhat similar approach to Option 1 that someone else has used. In this project James sent me, a Microsoft dev used something like the below schema. (I'm not totally sure if he'd do step 3 like I did it, because his API doesn't actually use an Office 365 tenant, it just returns a hello-world-esque thing.)

To me, this is fairly similar to Option 1 security-wise. It just happens to use Azure to host instead of Lambda. Either way, if you have a token, you can make changes to the tenant; if you don't, you can't.

Possible security flaw with Options 1 and 2

If our skill is theoretically published as we discussed, I'm not sure if either option is secure. Our client secret is stored in Alexa Skills so - even if you can't see the secret - if you download the skill can you use it to access our Active Directory? According to the Microsoft Dev, it requires log in to Azure during account linking but I just don't have enough background knowledge on security to know if this is by-the-book secure.

Option 3?

I can't really see how else to do it, as I think the Alexa Skill requires the secret in order to link accounts. So I could use suggestions, or people to tell me what I've missed or misunderstood.

With the introduction of more comprehensive unit tests, testing has become a much bigger element of this project; it could therefore use better documentation to unify testing.

"This shouldn't be hard for me to fix."

It would be very useful to have a test Active Directory to get authorisation working, but this has proved a little hard.

Problems

• (I think) it's not possible to use my personal Microsoft Account because it doesn't have an Office 365 tenant.
• (I think) it's not possible to use a trial Office 365 account with a new Active Directory - at least not without working credit card details that allow a test charge to go through (for both the Office 365 trial and Azure). Even if this is possible, I think this route may be unnecessarily difficult, and not that helpful.
• I'm not keen to use my Turing email due to obvious security concerns.

Ideas

• Use a Turing account with minimal permissions (i.e. read and write calendars, and only for specific room accounts). If this is the way forward, I probably need to ask about the best way to handle this in Azure... If I'm going by my previous development plan (a simple AD App Registration that can grant tokens to anyone with the secret), I'd still be concerned about security during development as I know very little about security protocols, especially for web services.

The authentication protocol requires the skill to use a Microsoft App Registry to get a bearer Token. The Microsoft App Registry is working and giving out tokens, but the "account linking" handled by Alexa skills is not working on the web or mobile app.

According to this thread, the state and authentication code need to be in the redirect URL after a #, like https://layla.amazon.com/api/skill/link/{appid}?{query-string-if-present}#code={token}&state={state}.

However, from looking at Chrome dev tools, Microsoft seems to do this from the query string: https://layla.amazon.com/api/skill/link/{appid}?code={code}&state={state}&session_state={session_state}.

I'm stuck on this, and not sure there's a way to solve it without writing up your own API/middleware, which I do not know how to do. My next steps are going to be further research into the issue (I only really just encountered it); then contacting Amazon support to check if this is indeed the problem, and to see if there's a way to solve it. In the meantime this may also be worth doing in case of further issues: https://developer.amazon.com/blogs/post/TxQN2C04S97C0J/how-to-set-up-amazon-api-gateway-as-a-proxy-to-debug-account-linking.

It would be useful to have the name of the owner of the calendar, as well as the calendar name.

• Most importantly it would mean that the invites sent to the rooms would use the right name; while this doesn't seem to matter right now, it may matter in the future, which is a good feature to have.

• If the room calendar names don't have clear names, I could use the owner names instead, which may be clearer.

I found out that there's some server-side paging done by the Graph API, meaning that you only get 10 calendars at a time when you make a calendars request. This means you currently can't really add any more rooms to it. I need to improve the getCalendars function so that it's able to get every single calendar.

The problem is this may mean several synchronous API requests, which would be slow. Therefore it would be good to parse the calendars and only make the next request if one is missing, and if there's another page available.

Currently testing only tests if a response is theoretically sent to Alexa. It'd be better if it checked that the right response is also sent. This requires some fairly annoying comparisons in Mocha, and precisely generating all the possible responses.

StartOverIntent doesn't seem to totally reset the state to blank on testing with the Amazon Echo. This needs to be diagnosed using actual lambda rather than lambda-local, so will take a little time.

It's possible that adding this.handler.state = '' to LaunchRequest will fix this automatically, so that's the first thing to try.

With planned changes to the ASK SDK, my entire testing suite might break. I need to consider this fact, and whether there's another way I can go about things.

The calendars must be explicitly shared with the [email protected] account before I'll be able to access them. Organisation-wide sharing does not seem to be supported by the Graph or Outlook APIs; I did test this and ask a couple questions online. I'll just speak to someone in IT/events and ask them to share the calendars with the [email protected] account, with read access to when the calendars are busy.

As I won't therefore have write access to these calendars, I think the best way to book rooms would then be the way everyone else does: [email protected] would make an event on 'her' calendar, and invite the room account to the event. Doing it this way may mean I need to check whether the event is accepted, or risk some errors. This is absolutely possible, but I'd be a little concerned about time and timeouts, as it may take some time for the room to accept...

It's not yet clear whether a room would accept an invite to an event created from the API on Alexa's calendar. This is worth checking.

Access token and request errors currently can cause crashes/time-outs, rather than functional Alexa responses.

Part of creating the lambda function right now requires you to copy an ARN into gulpfile.js. This is not a good thing, but it's proven a little annoying to get rid of. I am going to try to use the aws-sdk to do this, but this basically means creating an entire gulp plugin for AWS IAM.

Currently I suggest using Postman to get files, but I may put something together in Node/Passport to do this.

The way it detects calendars unavailable right now could use improvement.

New room names need to be added.

Sorry very new to this. How do I get a token using postman?

Due to issues combining lambda-local and mocha.js, I don't get great error callbacks on the Intents that access the Graph API. I'd like to improve these errors, but they do technically work.