A discussion on multiple authentication strategies


A discussion on multiple authentication strategies

1.Objective:

To design an online health care communication and data storage system that

• Allows medical practitioners and users to communicate via secure chat
• Allows patients to send pictures to doctors for diagnosis
• Maintains medical records and health insurance data
• Sets up calendar entries for appointments
• Allows patients to use their own devices (e.g,. smart phones)

What authentication strategy is recommended to be employed for this system, some of which will run on public cloud infrastructure?

2.What kind of authentication strategy do we need?

Medical information contains a large number of sensitive data. If effective encryption measures are not implemented in the process of collection, storage and transmission, the information will be in great risk of leakage.

(1) Confidentiality of data in motion

We need to protect the security and privacy of all data transmitted between patients and doctors, like messages and pictures. We need to prevent information from being eavesdropped or tampered with during transmission.

(2) Confidentiality of data in static

We must protect all stored data. Otherwise, if the patient’s medical records and other private information are leaked, the business operation, reputation and economic interests of medical institutions may be damaged, and the life safety and personal information security of patients will be threatened.

(3) Cross platform availability

Patients could have a choice of multiple devices to use the system, like smart phone and PC. It could bring users a good use experience.

3. A succinct description of Several different strategies

(1) Kerberos

Kerberos is a network authentication protocol, which uses symmetric key to authenticate “user’s access to network services”. Symmetric key means that both sides of sending and receiving data must use the same key to encrypt and decrypt plaintext, so the password does not need to be transmitted in the network.
The network security problem solved by this protocol is mainly in the “user access network service” part. The traditional authentication is carried out in the server. The server stores the username and password information to compare the authentication information input by the user. The password is transmitted in the network (usually not encrypted), and the hacker can intercept the plaintext password by sniffing the network traffic.

Kerberos is designed to introduce a third-party “KDC service” for authentication. In practice, when a user logs in using “enter password, fingerprint, smart card, etc.”, the system automatically obtains the user identity certificate from KDC, and then requests the service certificate when accessing some services.

(2) SAML

Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password: [2]
• No need to type in credentials
• No need to remember and renew passwords
• No weak passwords
It is used to exchange authentication and authorization data between parties, especially between an identity provider (IDP) and a service provider (SP)

Figure 1. SAML SSO Flow [2]

(3) Mutual TLS

Compared with TLS, Mutual TLS requires not only the server but also the client to provide certificate and authenticate certificate.

Mutual TLS (mTLS) authentication ensures that traffic is both secure and trusted in both directions between a client and server. It allows requests that do not log in with an identity provider (like IoT devices) to demonstrate that they can reach a given resource. Client certificate authentication is also a second layer of security for team members who both log in with an identity provider (IdP) and present a valid client certificate. [3]

Figure 2. How mutual TLS works [3]

(4) OpenID Connect&OAuth2

OpenID Connect is an authentication protocol based on OAuth2. OpenID is for authentication
and OAuth2 is for authorization. Following is an example of their joint use:

(1) A user wants to access its “service.com” account.

(2) “service.com” prompts the user for his OpenID.

(3) The user gives his OpenID, which is a URL, such as “http://user.com”.

(4) “service.com” jumps to user’s OpenID provider “openid.com”.

(5) User logins in “openid.com”, by entering the username and password.

(6) After passing the certification, “openid.com” jumps back to “service.com”. It allows the user to access his account in “service.com”.

(7) After autentication, the user wants to import information from “oauth.com” into “service.com”.

(8) “service.com” sends the user to “oauth.com”.

(9) The user logins in “oauth.com” using OpenID.

(10) “oauth.com” asks if the user wants to authorize “service.com” use his information at “oauth.com”.

(11) If the user determines, “oauth.com” sends users back to “service.com”.

(12) Finally, “service.com” gets the information from “oauth.com”.

Step (1)-(6) is the authentication process of OpenID Connect. Step (7)-(12) is the authorization process of OAuth.

4. So which one is best and why?

The recommended authentication strategy is OpenID Connect which uses OAuth2 framework. The following are the reasons:

(1) About Kerberos

It has a few disadvantages:
Its primary goal is to prevent unencrypted passwords from being transmitted across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication — the KDC — the entire Kerberos authentication system are at risk. [1]
For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. [1] This makes it possible to have problems with multi device compatibility.
So it is not a good choice for this system.

(2)About Mutual TLS

This strategy definitely uses extra work because it requires the client to provide certificate and authentication. Meanwhile, it requires that certificates be configured on different devices of users, which causes low cross platform availability. So it is not a good choice for this system.

(3)About Facebook Login

Facebook login could be one of special application scenarios of OpenID Connect. However, Facebook may collect user data and use it for business purposes. In addition, even if Facebook is a very widely used social media, there will be some people who don’t use Facebook. So it is not a good choice for this system.

(4)OpenID Connect&OAuth2 vs SAML

SAML ensures security through encryption, digital signature and other mechanisms. So the security level of it is very high, but the development process is too complex. SAML is more suitable for enterprise internal user authentication.

However, the process of OpenID&OAuth2 is clearer, and it is not so complicated to develop, so it is suitable for ordinary user authentication. At the same time, it also meets confidentiality of data in motion, confidentiality of data in static, and cross platform availability requirements. So it is the recommended strategy for this system.

5. Citations

[1] Red Hat Customer Portal. 2020. Chapter 3. Using Kerberos Red Hat Enterprise Linux 6 | Red Hat Customer Portal. [online] Available at: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_smart_cards/using_kerberos [Accessed 13 October 2020].

[2] OneLogin Developers. 2020. SAML Tutorial: How SAML Authentication Works - SAML 2.0 SSO Flow Diagram. [online] Available at: https://developers.onelogin.com/saml [Accessed 13 October 2020].

[3] Developers.cloudflare.com. 2020. Mutual TLS Authentication · Cloudflare Access Docs. [online] Available at: https://developers.cloudflare.com/access/service-auth/mtls [Accessed 13 October 2020].

[4] Okta.com. 2020. What’S The Difference Between Oauth, Openid Connect, And SAML? | Okta. [online] Available at: https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/#:~:text=The%20main%20differentiator%20between%20these,industry%20standards%20for%20federated%20authentication. [Accessed 14 October 2020].


Author: Qingshan Zhang
Reprint policy: All articles in this blog are used except for special statements CC BY 4.0 reprint polocy. If reproduced, please indicate source Qingshan Zhang !
评论
  TOC