So from what I understood:
* if I want to do something like "there's this inbound identity with a given `sub`, check if it matches an internal gluu user `inum` or `username` and log them in", I have to do that through the Jython script?
* Passport is simply managing the auth flow before the normalized claims are sent to the Jython auth script?
* Passport requires a `/userinfo` endpoint to be specified (maybe?)
> But what is the sub coming in from the external IDP?
The `sub` coming in would be the gluu `inum`.
We play the role of the external IDP. We don't actually own or store any identity, thus the SCIM API query to gluu.
My initial integration idea was:
* you create an OIDC client on our side (tru.ID) with a `redirect_uri` that points to your gluu installation
* you configure an Inbound Identity Provider on gluu, with the credential information obtained from the previous step
* you run a sample app that will handle the phone verification flow
Then all the user has to do to login with their phone is:
* when presented with the gluu auth screen, click the new Provider entry to login
* they would be redirected to a tru.ID page to input their phone number
* perform the phone verification
* on result, they would be redirected back to gluu, so their external identity could be mapped to an existing gluu User