Multiple Okta groups - Self-Service portal - registration

Hello guys,
I have a project that is using Tyk Gateway. This API Gw needs to have policies passed via group membership using a custom field so once a user becomes a member of that group the policy (custom field) is added from the group config.

We will have 4 web apps. It is possible to have 4 diff self-service portals for registration so we could have 4 diff groups per app or we need to have 4 tenants in okta so the split is possible?

Currently with the free version I can configure only 1 group in the self-service portal.


self-registration is allowed into a single group only, so if you don’t have a way to segregate your users based on maybe some attribute they would provide during registration, then you are out of luck with a single tenant

Your suggestion is for example in the registration process having a mandatory field where the user would set the value ( or prd) and based on that drive the claim pol value ? If yes, it is possible to have field validation so it is possible only to accept dev,qa or prd strings? If nothing is provided default to prd. Then it is possible using the okta expression language to read that value that I believe is stored in the user profile and then set the policies (uuid string ) hardcoded long numbers via okta expression language. Example: if my custom profile value = prd use this policy 1111111111. Makes sense ?

field validation can only be achieved if you implement an external service, which will be invoked with Registration Inline Hook.

Based on the field you can assign user to a group and give them access to a specific application (one of 4). here you can use fallback to a default group (giving prd access), if none of values in the field satisfy

I see your point, do you have an example of such implementation ?

No, I don’t, but it should be a no-brainer, the outcome of the service is "{ …, “action”:“deny”} if the field validation fails, so the user is not registered/created as a result. Check Okta documentation on this topic

yeah, will check. I think the reply of the service will be the policy string itself like a switch dev -> this policy and so on…if nothing specified return prd -> policy. This is a good starting point looks like.