Authenticating and logging in users

[peteryates]

The application will have several kinds of users, all of whom need to be able to log in securely.

Current situation in ECF1

ECF1 does this using a magic link system:

1. person goes to the landing page and clicks 'Sign in'
2. they are prompted to enter an email address
3. if the email address exists a token is generated and saved on the user record
4. the token is also embedded in a link which is emailed to the person
5. the person receives the email and clicks the link
6. the token in the link is compared with the one in the user record, and if they match the person is logged in and appropriately redirected

The authentication is handled by Devise, a large complex gem that supports several authentication strategies, but we had to add custom code to make it work how we want.

How we want it to work in ECF2

Some further investigation is required to confirm these assumptions, but in ECF2 we want two options available for logging in:

DfE Sign-in

Using email addresses causes many problems. Between Jan 1st and 19th March 2024 there were 198 helpdesk issues raised around school admins logging in. These include (note the term SIT isn't accurate, we now call them school administrators or school admins):

• SIT has left school and new SIT is trying to log in​ and asking for help​
• No SIT registered at school and trying to add them to the school for the first time​​
• Teacher is trying to log in and has contacted us as they get stuck in a loop - we advise them who the SIT is and advise them if it needs to be changed to contact us or nominate a new one through the service

In addition to email-based login, admins at schools are likely to already be using DfE Sign-in. Once set up this application will appear in the list of available services and login will happen in DfE Sign-in, we'll only need to hold minimal information (if any?) about the person in the database.

Magic link or one time passwords (OTP)

Not all our users will have access to DfE Sign-in. Some schools won't have registered for it and users from Lead Providers, Delivery Partners and Appropriate Bodies probably aren't eligible. We'll have to provide some kind of fallback, and using magic links or a OTP is sensible.

An advantage of OTP over magic links is that some people are likely to receive emails on a device other than the one they're using to access the service (i.e., trying to log in on laptop, emails received on phone).

Tasks

• [ ] Integrate with DfE Sign-in
  • [ ] find out who DfE Sign-in is available for. We know schools can access it, but can all ABs/DP/LPs etc]? @claire-hughez's comment below provides more information
  • [ ] work out the best approach for doing this as there are several in use across Teacher Services:
    • use a openid_connect and the original reference implementation for inspiration
    • use an pre-made gem like OmniAuth
  • [ ] implement DfE Sign-in integration
• [ ] Add email based login
  • [ ] work out whether to use magic links or OTP. My hunch is that OTP has some usability advantages
  • [ ] research the best approach, we barely use any of Devise's features so consider:
  • not using a gem and using Rails' built in features like #generate_token_for and build our own
  • use something lightweight and well-maintained, like Thoughtbot's Clearance
  • [ ] implement email based login
• [ ] Make sure both approaches work consistently and don't interfere with each other

[claire-hughez]

I wonder how DFE Sign in authenticates their first user when they don't have approvers. They can't authenticate against itself!

It would be good to find out more on if there are any schools not using DFE sign in. I'm pretty sure most will be, and it's relatively easy to get set up, but that's an assumption to test.

I'd challenge Lead providers or Appropriate bodies not being able to use DFE Sign in. Again, understanding that better and what other services use to authenticate them might be helpful.

I just checked the ESFA service they have to use for funding purposes and that uses DFE Sign in.... another good reason to align it by using DFE Sign in for lead providers at least.

And the TRA's Appropriate Body Portal also uses DFE Sign in. So... feels like we're quite well covered!

Both Apply for teacher training and Register trainee teachers use a fallback for DFE sign in, but this is only when it is down and not working. We'd probably want something similar and it seems like it might be needed for the edge cases where a user couldn't use DFE Sign In.

Finally, checked how you can search for organisations, and there's a few identifiers on DFE Sign in beyond URNs.

Feel like we could check all the lead providers and appropriate bodies against this fairly easily. We could even ask the team for a CSV of all the orgs on there to check GIAS data against too.

[peteryates]

I wonder how DFE Sign in authenticates their first user when they don't have approvers. They can't authenticate against itself!

So I think you can sign up for a DfE Sign-in account without being attached to a school, then once you're logged in there's a Request access to an organisation flow (link goes to TV because DfE Sign-in doesn't appear to have any docmentation 🤷🏽‍♂️). My hunch is that if there are no approvers set up for that org, someone at DfE Sign-in's end confirms who you are (maybe by sending an email to the GIAS contact address!)