How RealMe works

RealMe® is about providing New Zealanders with easy access to online services. RealMe services are a government common capability offering core functionality to central and local government agencies, and to private sector organisations.

It's important to understand the difference between the RealMe login service and the RealMe assertion service when determining the possible fit for your organisation. 

There is a bit more to a RealMe integration than implementing a simple API, but this ensures a very secure and trusted federated service.

To integrate RealMe services you'll need to choose between the following two protocols:

• Secure Assertion Markup Language (SAML) v2.0 is an XML-based standard that defines messages for communicating a range of security related statements about individual parties, including their authentication.
• OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables clients to verify the identity of the end-user based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

When you're ready to get started, you can try it out now in the Messaging Test Service sandbox environment. 

After successfully connecting to the Messaging Test Service, the core steps for technical integration using SAML or OIDC describes what is involved in configuring and connecting your online service to the RealMe ITE and Production environments.

NOTE: Microsoft Entra External ID (EEID)

Initial testing by the RealMe team has demonstrated that there are several barriers to integrating EEID services with RealMe across both SAML and OIDC. The key issue is that EEID expects the users email address as a mandatory assertion/claim from external federation.  

Since then, Microsoft has released several updates that have addressed some of these challenges. Based on our current understanding, a client integrating with the RealMe Login service using OIDC will be able to use EEID, as Microsoft has resolved the email identifier limitation.

There remains uncertainty around integration with both the Real Me Login Service using SAML and the RealMe Assertion Service

RealMe SAML Login Service: EEID enforces a static tenant-level IssuerUri preventing applications from presenting unique EntityIDs when brokering authentication. The static IssuerUri also means that the required format for a RealMe privacy domain cannot be met.

RealMe Assertion Service: EEID has limited flexibility in how it consumes and processes claims (verified identity attributes) returned by RealMe. We are now awaiting the EEID OIDC External Claims Management private preview, so we can review and test to see if that resolves the outstanding issues.

As with any integration, we recommend that organisations undertake their own due diligence to confirm that their proposed solution will meet requirements when integrating with RealMe. That said, because DIA is actively engaging with Microsoft as part of our own assessment of a potential migration from Azure AD B2C to EEID, we are also raising any issues that are reported to us or discovered through our testing that may impact a client using EEID to integrate into RealMe.

If you have any queries please email us at integrations@realme.govt.nz