I could not find any clear documentation how OIN integrations actually work as far as technical details…
I noticed that some apps used separate sub-domains for their SAML URL (ACS) for example: https://xxx.zoom.com/saml/SSO, here sub-domain would be different for each tenant.
The configuration UI requires you to specify the sub-domain (xxx).
Some other apps use a fixed URL, for example: https://www.abacus.com/login/saml/assertion
I assume the end-point would use Issuer from the SAML assertion to determine the tenant.
In this case there is practically zero properties that must be specified for the integration.
I assume it should be possible to setup a url based tenant or perhaps include IssuerID into the URL?
along the lines of: https://www.sp.com/saml/Issuer/XXX
Also the web UI on OKTA for configuring specific app properties can be somewhat different for each integration. How does that work when publishing a new integration?
Do we need to publish some kind of template for the UI?
It would be hard to imagine that OKTA employees would be hard-coding the UI for each integration.
Where can I find more information on these technical aspects of OIN and what is actually involved when creating a new integration?
I’ve go through the OKTA docs I found, but they don’t really go into these technical details (Configuration UI, ACS patterns, what is actually stored in OIN, etc.)
Hello,
You may have already seen these documents but I will add links in case you have not.
Part 1 https://developer.okta.com/docs/guides/build-sso-integration/saml2/overview/
This will guide you through building the integration for your SAML application. Here you basically setup the application as if this was going to be the only tenant that installed the app. There is no dynamic ACS, it is the same procedure you would use if you were setting up a private integration for your tenant only.
Part 2 https://developer.okta.com/docs/guides/submit-app/saml2/overview/
Once you have the above integration working with your application then this link guides you through submitting it to the OIN. As part of the process it will show sample install guides from existing integrations that you can base yours off of. This is also where you will setup your ACS (dynamic optionally), and it will guide you through how variables are created. You don’t need to provide any template as Okta will use the application you created in the first part as a template, and then add the extra properties from the submission process to create the integration.
If you already have a SAML integration in your Org I recommend going through a mock submission process through the OIN Manager so you get a feel for how to setup the ACS, etc.