Supporting Shared Accounts via SAML

This article explains how you can extend and configure Okta within the shared account use case. Credits to Nicholas Connelly for sharing this approach.

Disclaimer: This approach is not part of security best practices because it can be exploited and be abused by rogue administrators. I would recommend to look at this workaround if you really need to support shared accounts.

Every once in a while, an organisation needs to provide access to a group of users using a shared account. Traditionally, shared accounts are normally solved through a password manager where the password manager will manage the shared credentials to a certain extent. The limitation with using password managers is that eventually the credentials (username+password) can be stored and sync through the end user’s browser.

Most enterprise applications support Single Sign-On via federation standards like SAML. Once an enterprise application is integrated via SAML, end users normally will get access with their own designated accounts (e.g.: john.doe@atko.com will only have access to jdoe’s account within the application).

Extending shared accounts over enterprise applications that uses SAML becomes a challenge as SAML wasn’t designed to handle the shared account scenario.

In this blog post, I’ll be providing a workaround on how you can configure a second SAML application within your Okta instance to support the shared account use case/scenario. This will require the usage of Okta’s API hence get your API or Postman skills ready.

Step 1: Normally on-board and integrate your enterprise application with Okta using Application Integration Wizard that uses SAML federation standards. Offical documentation can be found here.

Step 2: Once you’re done on-boarding your enterprise application. Open up postman or any API explorer tool you have and call the Get application API. In this example, we will be using https://{your okta domain}.okta.com/api/v1/apps/{appId}

To get the appId, you can basically open the recently on-boarded application in Okta and inspect the browser URL. The one highlighted is the appId, which is found normally after the /instance/<id>

Step 3: Once you’ve run the GET Application API via your API explorer of choice, you should get the following information as a response. What’s important to look for is the credentials sections and take note of the value kid. We’ll be using that later

Step 4: WIthin the Okta Adminstrator console, navigate back to your recently on-boarded application and go to the Authentication tab. Within the Sign-on settings section, inspect the sign-on method. Please note the value highlighted in the screenshot below. This will be the issuerId that we want to reuse for the second SAML application we’ll be on-boarding which will support the shared account scenario.

Step 5: Create a second SAML application, re-use the same Entity ID and SSO ACS Url you’ve used for Step 1. In my example, I’ve used Salesforce as my target application

Standard User Account Application vs Shared Account. Not much difference

Step 6: The biggest difference for the username for the shared account application is to hardcode the application username format to the shared account that will be shared across all the users.

For this example, I’ve used shared_marketing@atko.com

Step 7: If you downloaded the Okta postman collection, there should be an template within the Application section called Share/Clone certificate. We will be using this one to copy/replicate the certificate from the application you’ve on-boarded on Step 1 (Standard user application) to the shared account application you’ve on-boarded on Step 6.

An example would be like this: https://oktauniversity-oie.okta.com/api/v1/apps/0oaiyww3i2qdQNo1U697/credentials/keys/oWZcSCGM8l4gZFMDIGcPssz8KYp4DOWfsWyA_1HDVsU/clone?targetAid=0oaiyx3p1o74yUZ55697

{{appID} = the app Id you’ve noted down from Step 2

{{keyID}} = the kid you’ve noted down from Step 3.

{{targetAid}} = the app Id you’ll get on the second application you’ve on-boarded in Step 6.

Once you’ve completed the required parameters, hit Send.

NOTE: You’ll also need the API token from Okta that has been grated with Super Administrator rights to make this API call be successful.

Step 8: Run the get application API again but point it to the second app – https://{your okta domain}.okta.com/api/v1/apps/{appId of the second app}

Step 9: Copy the response and basically within your API explorer, go to body and paste the entire response you’ve copied.

Change the method from GET to PUT.

Remove the ID

Modify the response you’ve pasted but edit only the following sections:

Replace the kid in the credentials section with the kid you’ve noted down from Step 3

Replace the issuer value from https://www.okta.com/{{externalId}} to https://www.okta.com/{id you’ve captured from 4}

Click Send.

Step 10: Time to test everything out.

Let’s start first with the first application which is designated with the standard account

Let’s try now the second application which is designated for the shared account.

That’s wraps this blog article on how you can extend Okta to support Shared Accounts. Feel free to leave in the comments section if you’ve configured this as part of your Okta deployment