A Hitchhiker’s Guide to Identity Providers (Singapore Government Edition)
This article was written with contributions from Chew Choon Keat and Alex Ng.
SingPass, CorpPass, TechPass, *Pass — Which Authentication Method to Use?
When you build a user-facing application that requires user assignment, roles and permissioning — a natural decision point surfaces: what should I use to authenticate incoming users?
Do you use a regular email-password combination? Do you leverage on existing digital identities from other services like Google Accounts, Facebook Accounts, or Active Directory? If so, which of these identity providers/managers should you integrate with, and how do you choose one over another?
In the context of the Singapore (SG) Government, there is no shortage of choice integrations and identity providers/managers. The usual suspects: SingPass, our universal digital citizen identity. CorpPass, sister of SingPass, it ties the individual to a corporate identity for business-related transactions. sgID, an identity provider that uses a privacy preserving protocol shipped with your SingPass mobile app.
Then there is TechPass, an offering aimed to provide tech-related identities to access developer resources on the Singapore Government Tech Stack (SGTS), but whose usage has been expanding beyond SGTS due to the ease of onboarding non-government users who do not possess @*.gov.sg emails.
Today, we have the humble ambition of simply providing a framework in which to navigate the existing landscape of *Passes and identity providers available — so the next time you create an application, you might pick up this guide and call it a day.
Here it is.
The Starter Guide
Easy enough. Almost too easy. But wait, you say. Aren’t there applications that may not fall neatly into any one of these decision tree paths?
True. Let’s take a closer look at one part of this flow chart.
Public versus Administrative Site
How do we qualify “mostly government officers” or “mostly private citizens”?
“Mostly” is a contraction for — in what capacity are your users logging into your application. Consider that, government officers are also private citizens, so the two roles are not mutually exclusive.
What is important to the “private citizen” application is that the user has a valid SingPass account, not that the individual is working for the Singapore Government in some capacity.
Largely, we see a pattern where there is a general public facing app, and a backend “government officer”-facing app for officers to make updates and configuration changes within one application ecosystem.
General Addendum — Who Are You
How does an application determine in what capacity its users should register themselves?
An application might first consider who are their “primary” users — who was this application’s target audience when first conceptualised? And what is critical about these users; for example, is it critical that these users belong to registered businesses in Singapore, that these users are direct employees of the Singapore Government, or that these users are residents of Singapore?
Then an application might consider what information it requires from its users — if the application requires information from the very popular MyInfo service for example, then an integration with SingPass is unavoidable as SingPass authentication is the first step in MyInfo integration. Conversely, CorpPass authentication is not required for an application to retrieve company information via the Enterprise Data Hub (EDH) — though EDH serves as a parallel source of data to MyInfo. Metaphorically speaking, EDH is to companies what MyInfo is to individuals.
Who are your users and what information do you require from them?
Thirdly, the application might then consider if access to the application should be restricted, and to whom. There are many ways to restrict access to an application, with the mode of authentication being one of them. Those who do not possess the required authentication mode, are excluded.
In this way, your identity provider can help to manage who has access to your application. Users who lose access to an identity provider will no longer be able to access your application. This works well in the SingPass/CorpPass use case but might not be so relevant for commercial integrations like Google/Facebook/WeChat/X.
A Chinese mega app might have integration with WeChat whilst others would have one with Google. As there is no barrier to entry for creating an account in the latter group of Google/Facebook/WeChat/X, except perhaps that of digital literacy and maybe geopolitical boundaries — it is unlikely you would use ownership of these accounts as a means of determining eligibility to access your application. If anything, exclusions of users who don’t own these accounts tend to be unwanted side effects, rather than deliberate prohibitions.
If your user base is not solely determined by a single or multiple identity providers, you may have to offer another bespoke login method and manage the list of accessing users yourself.
Definitions and Details
I’ve been liberal with the descriptions of “mostly government officers” and “mostly private citizens” — to aid with initial understanding. We can be a bit more rigorous now.
Precisely speaking, a SingPass account can be registered for not only by Singapore Citizens, but by Permanent Residents, and by Foreigners working, studying and residing in Singapore — essentially those who own a Singapore Government issued National Registration Identity Card (NRIC) or Foreign Identification Number (FIN). Foreigners who are not residing in Singapore but have assets or businesses in Singapore have to register for a SingPass account via a special route known as the SingPass Foreign User Account, that can be used with select government agencies only.
A CorpPass account may be registered for if a company has a Unique Entity Number (UEN), which means it is a Singapore-registered business entity; or via SingPass or Foreign ID, if it is a Foreign Entity.
Government Officers who are employed within Ministries and Statutory Boards are issued *.gov.sg emails but vendors and contractors who work for and with the government are not. They retain their own company’s entity email address.
This brings us to a further zoomed in portion of the guide.
A Deeper Dive into TechPass and WOG (A)AD
Whole-Of-Government (Azure) Active Directory — An Overview
WOG (A)AD stands for Whole-Of-Government (Azure) Active Directory. Azure Active Directory is the cloud version of Active Directory, an identity provider from Microsoft, and widely used in many corporate IT systems. For the rest of the article, we will use WOG AD to refer to both the Azure and on-premise versions of WOG (A)AD.
When one enters government service, one gets a *.gov.sg email. At the same time, one is able to search for myriad other users, anyone* who has a *.gov.sg email on one’s government-issued laptop, as all these addresses reside in the same Active Directory and have been administratively configured with these access resolutions. This means that even though I belong to GovTech, and have a tech.gov.sg; I will be able to search for a user who has a hdb.gov.sg or nea.gov.sg email on Outlook or Skype for Business. WOG, indeed.
I put *anyone as a caveat because as it turns out, there are two. The first is the Ministry of Education (MOE) — teachers are not automatically listed in WOG AD. However, you may see Head of Department (HOD) emails, non-teaching/Ministry staff or staff who have specifically requested to be listed in WOG AD.
The second is the Ministry of Defence (MINDEF). Like MOE, they have a separate Active Directory from WOG Active Directory.
So WOG AD is truly WOG, except for teachers and MINDEF. If your application requires logins from either of these two exceptions, you have to integrate with each separately.
Alternatively, you have another option, TechPass.
TechPass — Key Points
TechPass was created to provide tech-related identities to access developer resources on the Singapore Government Tech Stack (SGTS). SGTS includes development platforms like SHIP-HATS, government-hosted GitLab and the Developer Portal. However, its usage has been expanding beyond SGTS due to the ease of onboarding non-government users who do not possess @*.gov.sg emails.
So, our decision tree branches may have to be updated soon.
A few things about TechPass. Unlike WOG AD, which a user gets by virtue of their government email, TechPass requires all users to do a one-time sign-up. TechPass also allows non-WOG AD users to sign up for an account.
WOG AD and MOE AD users sign up by themselves, whilst non-WOG AD users need a WOG AD user/TechPass Admin to request provisioning an account for them. Examples of non-WOG AD include our MINDEF personnel, GeBiz personnel and any other non-*.gov.sg email entity. Reference here.
TechPass acts as a wrapper for other ADs. TechPass itself has an Azure Active Directory of its own, to house and absorb all other accounts that do not exist in an integrated AD. For WOG AD and other supported AD accounts, TechPass routes the authentication back to the respective integrated ADs. For WOG AD account closures, TechPass is notified via Central Accounts Management (CAM). MOE recently became another one of the ADs supported by TechPass.
This means that in terms of user base, TechPass is larger than WOG AD.
In terms of on-boarding, TechPass has an additional step for WOG AD users, but its comparatively shorter time to onboard non-WOG AD users is attractive to some applications.
Comparing WOG AD and TechPass
When we consider WOG AD versus TechPass, we should think of them in terms of ease of on-boarding and off-boarding. Reach-wise, they can both reach WOG AD and non-WOG AD users. A vendor can be provisioned with a WOG AD account by being given a vendor.from_company@agency.gov.sg email, upon request.
But it is the manner in which the accounts are obtained and off-boarded that might have more bearing on what an application chooses to use — and ultimately will tell you what is “mostly”.
If my application is 90 percent WOG AD users, I would go with WOG AD. If my users already have TechPass because they need to for their daily work (development, for example), I might go with TechPass.
WOG AAD and TechPass both support SAML, OAuth 2.0 and OIDC. After all, they both use Azure Active Directory as their backbone.
Can TechPass replace WOG AD? Possibly. It’s in a position to more flexibly integrate with existing ADs that are siloed from WOG AD. If the onboarding to TechPass can be made seamless — for example, if consuming applications handle the onboarding in the background, transparent to the user — then there will be no degradation of experience to the existing AD user.
Crucially, the web-hook to TechPass when an integrated AD user (whether WOG AD, MOE AD or any other future AD) has been off-boarded must also work reliably — there shouldn’t be any additional manual step during the off-boarding process.
For now, the additional step to onboard to TechPass, no matter how simple — may be the main repellant to using TechPass for users and applications who have no need to access SGTS resources.
Real Life Examples and Use Cases
For Business Grants Portal admin users, there are multiple sites that require integration and the team has landed on a wrapper solution that integrates with TechPass, SingPass and CorpPass.
For the GovWallet admin portal, as the initial user base fell outside of WOG AD, the team has integrated with SingPass and will augment with an OTP sent to a user’s entity email. The email serves to restrict the set of users who can access the portal.
sgID is in the process of releasing an integration with Public Officer Core Data Exchange (POCDEX) so that government officers can log in to administrative portals using their SingPass mobile app.
For GoBusiness admin portals, our administrative site currently has a user base skewed towards WOG AD users. We will first integrate with WOG AD before expanding to TechPass in the future, as required.
Concluding Notes
We often see many applications in the wild offering multiple ways of registering for an account, be it via your email providers, and/or social media accounts. This in addition to the good ol’ username/email-password combination.
Public-Facing Sites
For Singapore Government public-facing applications, the decision is often simple — SingPass, CorpPass, or both.
Administrative Sites
For Singapore Government administrative-facing applications, there isn’t a clear directive. We think there could be a number of configurations and proliferations.
WOG AD would be the natural option, if not for the necessarily segmented AD landscape and our significant collaboration with non-government body entities.
TechPass started as an identity provider for Singapore Government tech resources, but could grow to replace WOG AD, if the onboarding process for WOG AD users can become a non-step.
The above two are the incumbent options for administrative sites on both internet and intranet today.
However, we also see a gap where the distinction of “government officer” is fuzzy and the user base does not fall squarely into WOG AD or within the SGTS use case.
In situations where there is a significant portion of your user group that neither falls under WOG AD, nor can be easily onboarded to TechPass — SingPass and CorpPass, would then be an option for an internet-facing site.
The drawback would be the lack of definition on who the target user group is, as in most cases it would not be the entire set of CorpPass users or SingPass users who constitute the target group for an administrative site.
This would require some other mechanism to keep track of, or “whitelist” valid users within the application itself, such as by email, company, or a data set within a data exchange.
CorpPass would allow user management at the CorpPass Admin Portal by the individual entity’s CorpPass Administrator, though the role granularity at CorpPass will not necessarily be enough for access control within an application. One might have to additionally designate specific allowable companies on the app-side.
SingPass would almost certainly require another app-side whitelist for users.
Today, there are already agency users who log into public-facing government sites with their statutory board UEN as part of their CorpPass account identity. Fun fact: MOE and MINDEF both possess UENs.
Do we recommend using SingPass/CorpPass (SPCP) as a catch-all in an Administrative site? If your Administrative site is internet-facing, it could eventually be considered a legitimate login if SPCP itself is able to provide sufficient, and updated information about officer validity.
Perhaps we might then see something like this:
CorpPass should be considered before SingPass if your users are attached to entities and the entities play a meaningful role in authorisation within your app.
SPCP should be a last resort if your app has to maintain a separate whitelist of allowable users and/or companies even after integration.
As our user bases grow, shrink, morph and adapt — each application will make the assessment of which provider gives them what they need, and in the case of multiple options, balance ease of integration with user experience. Ultimately, we might see applications that support many login options, build wrappers that integrate with the choices, or come up with supporting validations that augment the existing list — not unlike that of commercial offerings.
Acknowledgements
Damien Ngor provided invaluable references on TechPass and Lai Yongquan provided needed context on the now-defunct CommonPass. Kwa Jie Hao provided feature notes on sgID. Janice Tan, Hoon Ding Yi, Vincent Tan assisted in finding these resources. Special mention to co-contributor Choon Keat for bringing GovWallet’s authentication journey to the fore during our group catch up sessions. Steven Koh triggered this exercise to document the Singapore Government Identity Provider landscape.
To all who reviewed the article and provided feedback, comments and insights: Ryan Goh, Salihan Zaol-kefli, Patricia Zhao, Dominic Phoon, thank you.
