Okta Integration Phase 2 (Session 1): Integrate first production Snowflake account
melanie-logan opened this issue · comments
We need to begin Phase 2 of Okta roll out by integrating the first production account with Snowflake.
- Identify first production account to integrate
- Create a backup user in production accounts in case we need to roll back changes.
- Set up security integration script
- Determine username mapping in Okta for integration
- Update user login values for all ODI users
Notes:
- Production Account: We decided to use CDTFA for first production account to integrate.
- Backup account: The backup user created across accounts is TESTUSER.
- In Okta, we can define username patters using Okta Expression Language, but it was determined that within ODI, the global default is set to email for username. Because of this, all Snowflake user account "Login Name" value must be ODI email address. All values will be updated.
- After updating the login name, integration and login was successful for both SSO and local login.
@melanie-logan I just tried to log in here, a few notes of what I ran into:
- I was no longer able to log in with username/password. Is this expected?
- I had to MFA twice, once for Okta and once for Duo. We can probably turn off Duo for user accounts, right?
- How is the Okta integration currently mapping to my old username? I somewhat expected to have a fully new user account associated with okta and my email
- Are there any user groups configured in Okta for, e.g., admins, IT-Ops, developers?
- Local login should still work, but your username is now your ODI email address, although ODI staff are advised to use SSO only. If it doesn't work, please let me know!
- Yeah, that's good point. We haven't disabled MFA, but I think it makes sense to disable. I'll confirm with Kevin during our next session.
- I thought the same, but since the users are added to Okta first, it is able to authenticate via email. To accommodate this, "Login Name" field was changed to ODI email within Snowflake:
- Currently, it looks like groups are by department, but can be further refined. We haven't tested provisioning users/permissions yet, but we just received the group of IT admins to add. I plan to work with Kevin tomorrow to demo how it will work.
Great, thanks for the info! I just had another thought: how does this work with programmatic access? If I'm using dbt or a python session, can I log in using okta? Do I need to use 'externalbrowsder' authentication?
Once we feel confident in the Okta integration, should we turn off password access for, e.g., everyone except admins?
@melanie-logan I just tried to log in here, a few notes of what I ran into:
2. I had to MFA twice, once for Okta and once for Duo. We can probably turn off Duo for user accounts, right?
I don't think there is a way to disable MFA in the admin console (at least not that I can find), since it is managed at the user level.
I'll see if there is a way to manage using Okta today.
I also agree we should disable local login for ODI users that are non-admin.
Ahh okay, I'll try that. Thanks!