Our guestbook application is open to all and lets anyone with the public IP access the service. The image by itself has no authentication support and we cannot request the code authors to add authentication just for us. A common problem is wanting to apply policy separately from implementation. The common approach used for this purpose is the sidecar pattern (https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar). It is similar to aspect-oriented programming.
Authentication deals with verifying whether you are who you say you are. The normal verification system is via username and password. The assumption is that only you know your username and password and therefore you are the person who is logging in. Obviously, with recent hacks, it has not proven to be sufficient, hence the implementation of two-factor authentication and multi-factor authentication. On top of that, it has become very hard for people to remember their multiple user accounts and passwords. To help alleviate that, authentication is provided as a service by multiple providers with support for OAuth or SAML. Here are some of the well-known providers:
- Google (https://github.com/pusher/oauth2_proxy#google-auth-provider)
- Azure (https://github.com/pusher/oauth2_proxy#azure-auth-provider)
- Facebook (https://github.com/pusher/oauth2_proxy#facebook-auth-provider)
- GitHub (https://github.com/pusher/oauth2_proxy#github-auth-provider)
- GitLab (https://github.com/pusher/oauth2_proxy#gitlab-auth-provider)
- LinkedIn (https://github.com/pusher/oauth2_proxy#linkedin-auth-provider
In the following sections, we will use a sidecar implementation, oauth2_proxy, to implement authentication for our guestbook example.