SAML 2.0 Login with Okta as Asserting Party (IDP)

To configure Okta as Asserting Party, configurations in the 4ALLPORTAL as well as external configurations in Okta are necessary.

SAML Preconditions

Please note the general SAML preconditions here: SAML preconditions.

4ALLPORTAL: Relying Party and Asserting Party

This basic configuration generates the metadata required for the Okta configuration (likely configured by an external IT responsible).

1. Configure a SAML2 Relying Party (SP):
   • Go to admin snap-in Authentication/SAML2 Relying Party (SP)
   • Set Relying Party ID to a unique ID, e.g. "example40".
   • Save your Relying Party.
   • Click action "Generate Decryption certificate" from the toolbox to generate both Decryption certificate (X509) and Key for Decryption certificate.
   • Click action "Generate Signing certificate" from the toolbox to generate both Signing certificate (X509) and Key for Signing certificate.
   • Save your settings.

Refer Relying Party configuration for detailed information.

2. Configure a SAML2 Asserting Party (IDP):
   • Go to admin snap-in Authentication/SAML2 Asserting Party (IDP)
   • Set RegistrationId (name) to a unique ID, e.g. "example40_okta".
   • Set Relying Party to previously generated "example40" (via the dropdown).
   • Save your Asserting Party.
   • Click action Show Metadata URL to copy the Metadata URL or click action Download Metadata file to download the Asserting Party Metadata file for step 4.

Refer Asserting Party configuration for detailed information.

3. Clear the configuration cache in admin snap-in General system configurations/System settings/Maintenance.

4. Give your Metadata URL or Metadata file to your IT responsible for external AD FS configuration.

External Okta Configuration

For the external part of the configuration, pass the required metadata to your (external) IT responsible. The configuration can be done/tested with an Okta developer account.
The configuring person needs to make the following steps:

1. Open Okta with an Okta developer account. Go to "Applications" and click "Create App Integration":

2. Select "SAML 2.0":

3. Fill in the General Settings and set "App name", to the name of your Asserting Party for clarity, e.g. example40_okta:

4. Configure SAML and make the following settings:

Field in Okta	Value	From 4ALLPORTAL Metadata file
Single sign on URL	Example: https://example40.4allportal.net/login/saml2/sso/example40_okta	Element: AssertionConsumerService Attribute: Location
Audience URI (SP Entity ID)	Example: https://example40.4allportal.net/saml2/service-provider-metadata/example40_okta	Element: EntityDescriptor Attribute: entityID

Add the following attribute statements if you want to access them in 4ALLPORTAL:

Name	Value
email	user.email
firstname	user.firstName
lastname	user.lastName

If you want these attributes to be copied to the 4ALLPORTAL, look how to map the attributes here.

5. Give feedback:

6. Go to tab "Sign on" and click View IdP metadata on SAML Signing Certificate:

7. Copy the browser URL (Asseting Party Metadata-URL). Give this URL to the person who configures the 4ALLPORTAL.

8. Assign user to SAML: Go to tab "Assignments". Choose "Assign", then "Assign to People" and assign a user:

Complete Configuration in 4ALLPORTAL

The last steps can be done as soon as the person who configured Okta externally provided either Metadata URL or Metadata File.

1. Go back to your Asserting Party in admin snap-in Authentication/SAML2 Asserting Party (IDP).
2. Set Metadata URL of the Asserting Party, e.g. https://dev-200xxxxx.okta.com/app/exk6gx3yjdymt7bga5d9/sso/saml/metadata.
   Or use the Metadata File instead of the URL if you wish or in case the URL is not accessible.
   Or fill all advanced fields below.
3. In Mappings, set Default role ID, e.g. to User.
4. Configure CORS like described in the basic SAML configuration here.
5. Reload 4ALLPORTAL.
6. Test your configuration and login to 4ALLPORTAL with the new provider.

Troubleshooting

If any problems occur during configuration or when logging in, look for help here.

Optional: Map Additional Attributes

With the configuration described above, only attribute user.external_id in 4ALLPORTAL will be set. This is sufficient for login, but a user will contain no further information.

If you want to map additional attributes, you may add attributes to your mapping in admin snap-in Authentication/SAML2 Asserting Party (IDP) e.g. like this:

example for mapping of user fields in 4ALLPORTAL

Without this mapping, the configured attributes in Okta are transferred but not copied to the 4ALLPORTAL.

Show SAML attributes

If you do not know the names of required attributes, use URL {baseUrl}/saml2/info to show SAML attributes after a valid login.