Hi,
We have 3 apps (iOS, Android and node JS) interacting with a custom Ignition 8 module (there’s also a web service involved which is the one communicating directly with Ignition backend through custom module). Apps perform custom authentication against a custom database. Now idea would be to be able to perform authentication using OKTA. Specifically we are interested in OKTA authentication performed at gateway side (if that’s possible and makes sense). For that idea would be:
-
Configure a new Identity Provider for OKTA (using customer’s OKTA settings). For testing purposes we already downloaded Connect2id (https://connect2id.com/), registered Ignition 8.0 as a client and configured a new Identity Provider accordingly using test settings provided by Connect2id.
-
Update apps / custom module to perform user authentication making use somehow of SDK’s Identity Provider available methods (of course addressing the OKTA IDP created). Probably using com.inductiveautomation.ignition.gateway.auth.idp.IdpAdapterManager?
The ideal scenario (please let me know if it’s feasible) would be not needing to modify apps but only custom Ignition module: apps already ask for user credentials (username and password) and send those to custom module, so idea would be to update custom module to interact with SDK’s Identity provider methods somehow to validate credentials and determine whether authentication was successful or not and then let know authentication result to apps. Does this make sense? If so, what classes/methods should I look into in SDK for that? If this does not make sense, what should be the general flow instead? And again, what classes/methods should I look into in SDK for that in case a module/SDK approach can still apply?
Many thanks in advance for your advice
Regards,
Carlos
Hi @pocewar -
So as I understand it, your three apps ask the user to provide a username and password credential, which are sent to the Gateway where the custom module is validating the credential against some database, is this correct?
Assuming it is correct, you now want to use Okta as an Identity Provider instead of using your own custom username / password solution. I am assuming Okta is an OpenID Connect Provider in this case?
The ideal scenario (please let me know if it’s feasible) would be not needing to modify apps but only custom Ignition module: apps already ask for user credentials (username and password) and send those to custom module, so idea would be to update custom module to interact with SDK’s Identity provider methods somehow to validate credentials and determine whether authentication was successful or not and then let know authentication result to apps. Does this make sense?
This will not work. The apps will need to be modified since the user experience differs drastically between traditional direct login and federated login.
If this does not make sense, what should be the general flow instead?
You will now need to call an API on the gateway to get a redirect URL to an Identity Provider, and you will need the app to follow this URL in order for the IdP to prompt the user for credentials. Once the IdP completes credential verification, the IdP will redirect the user back to the Gateway which can forward the control back to your module using a callback along with the authentication context.
What classes/methods should I look into in SDK for that in case a module/SDK approach can still apply?
Unfortunately, it looks like a crucial class is not exposed in the SDK right now and so I will need to file a bug to expose it so that you can use the IdP APIs. Once that class is exposed, here is roughly what you will need to do:
- Create a custom login route for your module
- In the login route request handler, create a IdP login callback
- Call the missing API with the ID of the IdP on the Gateway along with your login callback. In Perspective, the IdP is configured on a per-project basis from the Designer.
- Send the user to the URI returned from the missing API (in your case, the URI will be Okta). Mobile apps such as Android or iOS will have more complexity here as you need to leverage a special "brokered" auth flow. In the brokered flow, we redirect the user to a broker login route on the Gateway. Your app will need to identify that this broker url is targeted and should open the platform equivalent of a chrome tab with that URL (should not use a web view for security / privacy reasons). The app should also start a lightweight web server listing on a port of its choosing. Once the user logs in and returns to the gateway within the chrome tab, the gateway will post the login data to the port of your choosing at
127.0.0.1, where your app will forward back to the Gateway.
- Once the user logs into the IdP, they will be redirected back to Ignition, which will parse the authentication information from the IdP and forward to your callback, where you can do what you want with the logged in user. Your callback will need to return the URI to redirect the user (usually the original location they were before they triggered login)
I'll post back here when we expose the API you need.
Hi,
many thanks for your response and general roadmap for the changes to be done. Right, performing the whole authentication server side in this case does not match with security principle underlying federated login. SO it looks some work must to be done as well on apps side.
Please keep me posted when necessary “missing” class is exposed in a future SDK release so I can start look into it and specific changes to be done in the different layers. As mentioned in an edit I added to question I found an interface that seems to be related, IdpAdapterManager. Not sure if the “missing” class you mention implements it?
Thanks again and regards,
Carlos
Hi @pocewar -
IdpAdapterManager is definitely related, but there is a layer above which is missing and is required for you to be able to register the appropriate callback. I’ll keep you posted 
1 Like