We are a SP providing SSO and provisioning. When users are created via SCIM and imported into our account I can choose to auto confirm and auto activate them. I don’t understand how to combine SCIM with SAML due to this. When users are not auto activated but auto confirmed and they try to SAML SSO in they get an error “Pending Activation”. When they are auto activated they get an email, which we don’t want, we don’t want them to set a password. How do I ensure they can SSO in with SAML without receiving activation emails? I was hoping JIT would auto activate their accounts.
At the moment, we do not have the possibility to active the imported users without sending an email.
I’ve moved this topic to the Feature Requests section in order to increase it’s visibility to the product management and possibly have it added on the roadmap.
@dragos that is really disappointing. We were sold SCIM as a solution for provisioning users for SSO. We also were quite clear that we wanted a “Big Bang” SSO app. There is no way to customize what email they receive? We were also told to force SSO we should automate a password reset and put SSO users in a policy that prevents all password actions. In this case Okta would be telling the users to set a password, which is definitely not what we want, we want a federated user.
Just to be clear, it isn’t possible to activate a staged user with JIT? That is what we want. User being provisioned and not being activated until they login via SSO?
Can you please open a support case with us at firstname.lastname@example.org in order to double check this functionality together with our engineering team?
Sure thing https://support.okta.com/help/s/case/5001Y00001KBtYpQAL. I will report back here with the answer. Currently I am wondering if we can somehow use import inline hooks to just auto activate users imported via the SCIM app without an email. Not optimal but that might work.
Is there any update on this? We are planning on importing large numbers of users using SSO and right now they are all going to be hit with emails (which we don’t want them to use). We also don’t want them to have any way of accessing/changing their password - the only way they should be able to login is using SSO with JIT account creation.
If this is not supported yet, were any workarounds from the support cases above discovered?