Opsera External Identity Provider Configuration (via OIDC)
- Todd Barczak
Opsera supports Okta to Okta account federation via Okta OpenID Connection (OIDC). In this process, both Organizations must use Okta for their user identify management. The customer will be responsible for configuring an External Identify Provider in their Okta account and share that with Opsera. Once complete all authentication will be managed through the customer’s Okta via Federated Identity.
Customers not using Okta for their account management can still connect with our Okta as the OIDC is an industry standard. However you are responsible for supporting and knowing how to configure OIDC based connectivity in your environment. Opsera will provide the necessary details but cannot support walking users through their side of the SSO configuration. As a standard OIDC, any modern Single Sign on solution should have details on how to work with the information provided below. Customers do NOT need to have Okta to use OIDC as it’s an industry standard. TL;DR for non-Okta Customers
How does Okta’s Single Sign-on Work?
If you are interested in reading how the SSO Integration with Opsera works, here is the documentation from Okta which we rely on for this service.
https://developer.okta.com/books/api-security/authn/federated/#authn-oauth-2
https://developer.okta.com/docs/concepts/identity-providers/
PLEASE NOTE: Okta Federation facilitates authentication only. Authorization is managed inside of Opsera using the platform’s Role Based Group Management and Site Roles. Users must still be added in the Users section of the Opsera Portal and granted the specific access via RBAC in order to use Opsera after these steps below are completed.
Getting Started!
Before getting started, the two big questions to answer are:
Are you an Okta customer?
If not, what do you use for as a Single Sign On provider AND will it support OIDC?
An Okta Customer?
As an Okta customer, the details in the Okta Customer section outline screen by screen what you need to do to setup Okta to Okta Federation. Get started now!
A non-Okta Customer?
As a customer using another identity management solution, you can still setup your service to work directly with our Okta Federation using the OIDC standard. Examples of setup documents are added in the appendix below. Get started in the next section below!
Non-Okta OIDC Customers
OIDC is a standard that virtually all SSO vendors support. Listed below are details you need to setup your identify provider and the values Opsera needs from you.
Values Required for Customer to setup their SSO
Sign-in redirect URI’s: (make sure both are registered)
Sign-out redirect URI’s:
Base URI’s:
Client acting on behalf of user: Authorization Code
Ensure users have access TO the app in your SSO
Please ensure BOTH sign-in redirect URI’s are included in this setup, otherwise it will fail.
What you must send Opsera (after you complete your setup):
After the above configuration is complete the following information from your setup must be sent to Opsera:
Client ID
Client secret
Issuer URL
Authorization endpoint URL
Token endpoint URL
JWKS endpoint URL
Userinfo endpoint URL
Okta Specific Customer Steps:
If you are an Okta customer, follow the detailed steps below.
Create a new Okta App Integration with OIDC - OpenId Connect and as a Web Application App type.
Values Required for Customer to setup their new Okta App
Configure the new APP with these values:
Client acting on behalf of user: Authorization Code
Sign-in redirect URI’s:
Sign-out redirect URI’s:
Base URI’s:
Assignments*: Controlled access: Up to you to choose as the SSO Admin but users MUST have this access in order to log in.
Please ensure BOTH sign-in redirect URI’s are included in this setup, otherwise it will fail.
*Assignments: You must ensure users are granted access to the new Application created in Okta if you want them to be able to log into Opsera.
What you must send Opsera (after you complete your setup):
Please send the following information to Opsera so we can complete your setup!
Client ID
Client secret
Okta domain
Congratulations! That’s it!!!!
Once Okta completes there setup based on the Client ID, secret and domain you sent, we’ll let you know when you are ready to start logging in!
How do I sign in now?
After Opsera has responded with confirmation of the settings being enabled, any user who is active in Opsera (preregistered in the Settings → User Management), can start using the connection. The login flow will change slightly as after the user enters their email address they must use the “Click here to sign in!” button. That will trigger the SSO workflow and bind the user record to your SSO/Okta. From that point you have complete control over that user’s ability to log into Opsera.
Appendix
Okta OIDC Federation Documentation: https://developer.okta.com/docs/guides/add-an-external-idp/openidconnect/main/
Other SSO Vendor’s Integration Documentation
Overall User Flow
The above steps can apply to non-Okta services IF they also support OIDC, however that should be reviewed and coordinated with Opsera ahead of time.
Okta Troubleshooting
Logging in causes: “User canceled the social login request” error.
Resolution: When the customer configures the Access Control for the Okta application, they have to define who has access to the Application. Shown above is the Opsera recommended value for Controlled Access of “Allow everyone in your organization to access” this APP. The customer Okta still controls who has access to the above created APP, and if the Customer Okta Admin does not set this properly, login events will fail with an error like this: User canceled the social login request. This error is saying that the customer Okta has canceled the federated login request because the user doesn’t have access. The fix is as noted to ensure that the Web App created has granted users who need to log into Opsera access.