There’s some of identity use cases we don’t yet support in our products:
Login against an external provider
RCPCH staff should sign on using our college Entra ID directory. As we have administrative privileges in our clinical audit platforms, we should use “single sign on” to make sure users no longer have access once they leave the college.
Our clinical audit teams spend time fielding password and two factor resets from audit clinicians. NHS staff in England could “single sign on” using NHSmail…
It’s possible to set this up for each software project we make but there are some advantages to doing so centrally:
- We wouldn’t have to submit an NHSmail single sign on request for every project
- We could do true “single sign on” without requiring a login screen in the future
- Using our NHS Organisations API, granting a role centrally could grant access across multiple tools
- We could extend single sign on to third party software we don’t write from scratch (eg the RCPCH website).
- We maintain a mini customer “CRM” within our Discourse forum (private link). By representing those users and in particular groups for each customer outside of the forum they could be used for authorisation in other projects.
This gives us a few requirements for said external provider:
- It must be an OpenID Connect compliant provider
- SAML is insecure, complicated and slowly being phased out
- It must support username, password and two factor accounts outside of federated login
- Some users (eg NHS outside of England) will not have the option to use SSO
- It must be a net-positive for our security posture
- Ideally it becomes an easy tick in future security audits
OAuth API credentials
We host all our APIs behind Azure API management. Surprisingly, per user, it only supports static API key credentials.
These are appropriate for APIs like Digital Growth Charts as they are entirely transient, stateless and deliberately store no personal information. In the future we are likely to take on projects that must do so and static keys are not secure enough.
The various OAuth flows are widely adopted to acquire time limited tokens. In particular the client credentials flow (client_id and client_secret) is suitable for machine to machine communication, under which I expect most of our future projects will fall. For example EHR systems could send patient data directly to our audit platforms.
As RCPCH administrators we need to be able to provision these credentials and share them with our API consumers. In the long term they will likely need to self-service manage such credentials too, in the same way as Google and Entra do via their admin UI.
Non goals
Our software projects, especially clinical audit platforms, will always have a built-in notion of a user and will always work without an external identity platform. A central identity provider should streamline and improves our integrations. Anything that makes them more complex, holds back their development or ties it to a single third party is not appropriate.
Hence we should pick a lightweight, single, standards based integration point of talking to an OpenID connect provider.
We are not looking to centralise the definition of groups - especially when it comes to defining roles and permissions.
Technology options
We do not necessarily need to have one system that supports all our use cases but they are sufficiently woven together that we can’t look at them in isolation.
Some options:
- Our own RCPCH entra directory
- Doesn’t support federated login (I think)
- Any new system would ideally be isolated to just identity operations for customer facing software products
- A strong security isolation between the two helps defence in depth
- Okta etc
- Cost
- Have to share data with another cloud company
- django-oauth-toolkit
- Requires us to manage a database in proportion to all our traffic and predict it into the future
- Harder to pass the “security audit sniff test” since we run and manage it entirely ourselves
This leaves two Microsoft offerings:
As the name suggests, the latter is the new product whereas the former is the existing option. We suspect AD B2C will receive fewer updates going forward and will probably be turned off within a 10 year timeframe.
As such, I’ve started testing Entra External ID. The decision is definitely not made though and I welcome feedback on my assessment, both for technology choices and on the split of responsibilities between our various components.