my company uses google for email and calendars and whatnot.
I am attempting to get our development server to use the GSuite OpenID Connect (OAuth2.0) because we have a couple different AD forests. All the AD forests are present in our GSuite. So, if i can create an identity provider with this GSuite connection. I can solve some problems and i’d like to see if perspective will bypass the login screen if the user is already validated in chrome.
I’ve got everything setup API Keys, Client IDs no problem and and that all looks good, but i am getting an error from the redirect URI.
Invalid Redirect: must end with a public top-level domain (such as .com or .org).
This is likely a security restriction that Google places on the redirect URIs you are allowed to use for your client. They’re probably requiring you to enter a URI whose host name portion contains a valid internet top level domain (and will probably require the protocol to be https unless you are using localhost or a non-public ip address such as 127.0.0.1 to access your development instance of Ignition from your web browser). You’ll need to set up a valid internet domain name for your Gateway or if its just a handful of you accessing this Gateway, you could each mock this out by editing your local hosts files and point an arbitrary domain name to your Gateway’s IP address. For enabling https, you will need to turn on SSL / TLS in the Gateway, which requires installing an SSL certificate which includes the domain name you will use to access the Gateway.
I tried using 127.0.0.1 and get the same error. I am working with our infrastructure team to get the perspective project redirected to something like project.mydomain.com.
I think we need something along the lines of IIS running reverse proxy on the ignition gateway and our DNS servers to redirect those queries to the ignition server, but I am not sure exactly how to do all that.
I am trying to explain to my Infrastructure group what I need, but I am certain I am missing some details.
Did you literally enter 127.0.0.1 as the redirect URI? or did you enter http://127.0.0.1:8088/data/federate/callback/oidc? I would not expect the former to work but the latter should be accepted by Google (it is for me).
The scheme, host, and port in the redirect URI need to match what is in the URL you use to navigate to the Gateway from your web browser. Google allows you to use 127.0.0.1 and localhost as the host portion of the redirect URL since this is common for testing local environments, but if you use some other host name to navigate to your Gateway, then Google will only accept it if it is a fully qualified internet domain name (such as foo.example.com). If you do not have a domain set up for your Gateway, you could temporarily edit the hosts file on the computer(s) from which you launch your web browser and mock out a domain name of your choosing and resolve it to the IP of the Gateway you are targeting, but this mocked out domain name will only resolve on the computer(s) with the edited hosts files.
and that if i want: http://www.myproject.mydomain.com
to route to my ignition server then I need to IIS reverse proxy setup on the ignition server? I understand that DNS modifications will send all queries for http://www.myproject.mydomain.com to http://myignitionserver (or more specifically its IP address), but the reverse proxy needs to handle the port and the rest of the URL
It sounds like you are on the right track, though I can’t speak to your specific environment as to whether or not you need a reverse proxy. That really depends on your network architecture.
We set the redirect uri to http://10.180.191.48:8088/data/federate/callback/oidc and still see the error. Its a private IP but our OKTA server has access to it. I’m not sure where to go from here we are trying to get our development PC running ignition 8.1 so we can make the change to perspective.
Are you accessing your perspective project in your web browser using http://10.180.191.48:8088/? Assuming you have configured the same redirect URL in your Okta client app’s settings, it should work…
Yeah I see the issue, when I was using the Test Login from the browser I was using the localhost:8088 address. When I navigate in the browser to the 10.180.191.48:8088 the Test Logon worked. So when I put this into service if I have a local IP and a public IP will both redirect addresses need added to the identity provider for things to work from a local and public perspective.