We would like to use progressive profiling to ensure a user has entered an physical mailing address (in a CRM) for a specific application. I don’t want to have the 3rd party vendor worry about coding their application to check for the address.
Is there a way to configure progressive profiling so that upon login, via an inline hook, determine the address does not exists and present the user with a form to enter it, then continue onto the application. This ‘form’ would be a custom application that saves the data back into Okta profile once entered. I could do this part with Auth0, I just haven’t been able to find documentation of whether its possible with Identity Engine.
The Okta profile enrollment form won’t work here since addresses are complicated and require validation based on country (country and state drop downs come to mind), but we also use an external address validation service.
Have you looked into our Registration Inline Hooks? From what I can tell (I haven’t tested this yet myself), it should support Progressive Profile updates and your hook endpoint could help do some of this address validation and user will be prevented from completing the enrollment if your hook sets the action as DENY, as in this example: Registration inline hook reference | Okta Developer
I like the concept of the registration inline hook, but there is no mention of sending the user to a separate app to complete information. I’d like to be able to send users to a separate app. For example, address 2 is not required, but how to you make it optional when address 1 is required? The same goes for states when the country is not USA or Canada.
And for progressive profiling, I’d like to say, on the 7th login, ask the user their gender (and let them not answer). On the 10th login, ask them to verify their year of birth. Again, they can skip it.
Has anyone done this with OIE? Is this something that needs to be completely custom?
Sorry about the delayed response, I just saw this question.
You have three choices to handle progressive enrollment. One is to just have the application look at the user data (best way would be through /userinfo via OAuth/OpenID Connect) and prompt the user if something is needed that hasn’t been set yet. I realize that conflicts with your original statement about 3rd-party applications, I just wanted to mention it.
The second way to handle this is through the enrollment polices and progressive enrollment using the Okta Signin Widget for authentication (Okta hosted or embeded/self-hosted will work). You will add the attributes required to the user profile if they are not already there. Do not make them required in the profile, or they have to be there when a user is created. In the enrollment policy linked to the application add the attribute fields, and make them required here so the user has to put in the information before they are allowed to proceed to the application.
If you want to validate the user data (which was your requirement), add in inline-hook for registration. The property you want to look at in the data the hook receives is “userProfileUpdate”. You can accept or reject the data that the user provided. If you reject it, the user sees an error on the form and cannot proceed without fixing the data. Okta updates the profile and proceeds to the application if you accept the request. Look at the documentation for the registration hook here: Registration inline hook | Okta Developer. That will give you the starting point, but you are interested in the profile update not the initial registration. Note: if the user goes to the app and an attribute is required, the user is sent to the Okta-hosted Signin Widget to provide it.
The third option is to build your own authentication application to use instead of the widget. This would use the interact (IDX) flow and handles getting the attribute when IDX says the user has to provide it because of the profile enrollment policy. You have to use an IDX SDK for the flow, as an example see the one for JS here: okta-auth-js/idx.md at master · okta/okta-auth-js · GitHub. The advantage is no hook, your authentication can validate the data before it is sent back in the flow. The disadvantage is it won’t work with 3rd-party apps unless they can be configured to send the user to your authentication instead of through /authorize or SAML at your org which will land on the Okta SIgnin Widget. Generally we only use custom authentication for customer-facing environments where we code the applications.
Good luck, let me know if you need clarification on anything I said
I appreciate the feedback here. I have been reading this over and over and I don’t think any of this will work for my scenario. The last I want is a custom authentication application. I just wish the progressive profiling was built in a way that allowed for me to put something in between the Okta login process It would be something similar to what Auth0 allowed, although I am not sure if they still have that.
You first scenario makes sense for the basic fields, for example, favorite color, was needed. We may have other data not stored in Okta, which is a bit more complex. Address 1, Address 2, City, state, postal code and country. Some of those field are required based on country.
The second scenario seems like it would work, but it it javacript based? Does the page have to reload? In my current registration page, I hide the state drop down if a country other than US and Canada.
Lastly, the third scenario could work if we had the resources like Okta, to build and maintain it.
I am speaking to Okta PS team to maybe find another solution, if possible.