As with the previous answer - the key is to understand what is being sent and you can use a tool which shows the SAML response. For example I use the add-on "saml-tracer" in firefox. You can then see what attributes are being sent back to Splunk from Okta.
The issue is likely to be one of two issues
1) The user trying to logon is not assigned to a role. For example you have added to a group and the group is not assigned to a role. Ensure that you can confirm in your Okta idp, that the users is either added directly to the role or they are added to a group and the group is assigned to a role.
2) Splunk expects a very specific and case sensitive attribute called "role" - note lower case. If your idp sends this data in a different attribute name - possibly using the "Role" attribute (note upper case R). Then you need to modify the mapping in Splunk to map the "Role" attribute to the "role" attribute.
See below for the relevant section from the "authentication.conf" spec
* Splunk expects email, real name and roles to be returned as SAML
Attributes in SAML assertion. This stanza can be used to map attribute names
to what Splunk expects. These are optional settings and are only needed for
role = <string>
* Attribute name to be used as role in SAML Assertion.
* Default is "role"