The Tuakiri OpenID Connect Bridge allows to connect services using OpenID Connect to authenticate users into Tuakiri.
The bridge acts as an OpenID Connect Provider (OP) towards these services - and translates the OpenID Connect authentication request into a SAML authentication request, acting as a SAML SP towards Tuakiri.
The services is similar to Tuakiri RapidConnect, but is based on a proper standard (OpenID Connect) - which wasn’t yet available at the time RapidConnect was developed. Eventually, this service will replace RapidConnect.
The bridge runs SATOSA, an identity proxy initially developed by SUNET.
The bridge allows configuring Tuakiri login for services that are not able to participate in SAML, but support OpenID Connect (as an RP - Relying Party). The bridge acts towards the service as a single OpenID Connect Provider (OP).
Same as with other Tuakiri services, besides a Production instance, there is also a member-facing TEST instance registered into the Tuakiri-TEST federation, suitable for testing OIDC integration for services being developed.
All Tuakiri member organisations are welcome to connect an OpenIDConnect-compatible service with the bridge to use Tuakiri for authentication.
To provide a secure and trustworthy environment, the bridge does not allow self-registration and all registrations must be processed by REANNZ Tuakiri staff.
Please start the process by contacting us at email@example.com - and in your initial request, please include the following information:
We will respond with further instructions.
We will also need a way to communicate the clientID and secret to you in a secure way. For this, we use Keybase.io - so please also include your Keybase account ID in your registration request.
When configuring your service, you should be able to get most of the OpenIDConnect configuration URL served by the bridge.
The URLs are:
You will receive the clientID and secret from us via a secure message.
You will also need to configure your service to request the correct scopes - this way, the bridge would know what claims (corresponding to attributes) to expose to your service. The scopes and the corresponding claims are:
|openid||sub||This scope must be always present in OpenID Connect|
|Correspond to SAML attributes (in the same order):