I am building an application where we want to allow our users to sign in using their own IDPs, and we’re using okta.
We don’t want our users to have to:
Create all their organization users manually
Be dependent on SCIM (or any other synchronization)
Maintain many users that most of them will probably not use our system
Since our user ids are email addresses and all of our customers are enterprises, we want to map domains to IDPs.
Meaning that if example.com is a customer of ours, then all email addresses like alice@example.com or bob@example.com should be handled by their IDP. the thing is we want to make sure that they own the domain example.com before adding their IDP to our discovery logic.
We were thinking about doing a DNS validation using a TXT record, but we aren’t sure that this is the correct practice for this.
So finally my questions are:
Is there a common practice for this?
Are there downsides to the DNS record validation method?
Are there any caveats we should be aware of? should we re-validate the ownership periodically?
Hey tomer-amir, I’ve seen the TXT record approach with a number of SaaS providers (including Okta if you’ve setup a custom domain). So it seems standard? Usually a long, random string.
Can’t answer the other questions unfortunately! I don’t know enough about DNS
The broader trade-off with just in time provisioning to potentially be aware of (or make your users aware of) is that there will always be an active Okta account in your Okta org. A savvy user could potentially set a password in your Okta for their account (if the user knows what they’re doing and knows you’re using Okta). When a User terminates employment with their organisation, they can’t login via their IdP, but there is still an active account for them in your Okta.
You may still need to consider how users are deprovisioned/deactivated. SCIM is nice, open-standards way to do this automatically. You could also require your User’s organisation to have a manual cleanup process for a low tech/cheap/unsexy approach.
You could also look at prevention by setting policy to prevent users logging into your Okta org’s dashboard / accessing user management or a detection approach - you may want to monitor for set password / password reset events.
Monitor the system log for password set events for federated users and non idp-related. If you forward your system logs to a SIEM or log aggregator you could wired some rules there and have alerts.
Have a policy to purge inactive users (this could be done manually, scripted or you could write a process/service).
Implement a SCIM interface / API so customers can de-provision their users automatically.
Provide a delegate administration user interface (cut down UI) for a customer representative to manually deprovation their users. This could be done with Okta roles and the Okta UI, or you could build a customer portal.
