1. Help Center
  2. Security & Access Management

Identity Federation using OIDC or SAML

This feature is available to all customers with an active ProsperOps subscription. If you are interested in enabling this feature, please reach out to help@prosperops.com.

Introduction

ProsperOps supports several methods for logging in to our console:

  1. Email and password unique to ProsperOps
  2. Integrated authentication using Google credentials
  3. Identity federation using an OIDC- or SAML-compliant identity provider (IdP)

This article provides the steps necessary to configure OIDC- or SAML-compliant identity federation. While any OIDC- or SAML-compliant IdP will work, we provide specific setup instructions for the following common IdPs:

It's likely that you'll need a member of your IT team (or whichever group administers your IdP) to assist you with the configuration. If you'd like to configure an IdP that is not listed above, please contact help@prosperops.com for instructions.

 

Configuring Okta

  1. Log in to the Okta Administrator Console
  2. Go to Directory and create three new groups: ProsperOpsViewerProsperOpsEditor, and ProsperOpsOwner (these group names are case-sensitive).
    • If you have a corporate group naming standard that necessitates a different naming scheme, you may use custom group names.  
  3. Go to Applications > Add Application > Create New App.
  4. Select the Web platform and OpenID Connect sign-on method and click Create.
  5. Under Create OpenID Connect App Integration, enter the following and click Save.
    1. Application Name: ProsperOps
    2. Login Redirect URI: https://login.prosperops.com/login/callback
  6. Copy the Client ID and Okta Domain. You'll send those to us in a later step.
  7. Go to the General tab and look at the Application section. Check Implicit Hybrid and Allow ID Token with implicit grant type.
  8. Go to the Sign On tab and edit the Groups claim filter to only include groups that start with ProsperOps. If you created custom group names in step 2, instead create a filter that at least matches the three ProsperOps access groups in your Okta directory (for example, a regex match of .* will transmit all groups a user is a member of). Click Save.
  9. Go to the Assignments tab and assign the three ProsperOps groups you created in step 2 above.
  10. Populate the three ProsperOps groups created in step 2 with appropriate users. If you have local ProsperOps users, you can reference the user and role mappings on our User Management page to understand current levels of access. Once identity federation is enabled, all local ProsperOps users will be removed.

    Note: If a user is added to more than one group mapped to a ProsperOps role, the group granting the highest level of access takes precedence.
  11. In your email system, create an email distribution list (e.g. prosperops-users@mycomany.com) which will be used for all automated email notifications from the ProspserOps service (e.g. monthly summary emails, AWS account access alerts, etc.). If possible, we recommend you configure synchronization so the email distribution list always contains whatever members are in the three ProsperOps access groups.
  12. Email help@prosperops.com with the following:
    • The information you gathered in step 6 above (the data is not sensitive and does not require a secure transit channel).
    • The email distribution list created in step 11 above
    • The email address that should receive billing communications for your account (if not already configured)
    • If applicable, the custom group names from step 2 above

    We'll configure your company for identity federation in our system and provide you with steps to test the experience once configured.

    If you want your end users to be able to login to the ProsperOps Console via the Okta application launcher, configure a bookmark app using the Login URL provided on the ProsperOps User Management page.

     

    Configuring Azure Active Directory

    1. Log in to the Microsoft Azure Portal
    2. Go to the Azure Active Directory service
    3. Navigate to App registrations in the left nav under Manage and click New registration at the top of the main panel
    4. Fill out the Register an application form with the following information:
      • Name: ProsperOps
      • Supported account types: Accounts in this organizational directory only
      • Redirect URI
        • Platform: Web
        • URI: https://login.prosperops.com/login/callback
      • Click Register and the newly created application will open
    5. In the Essentials dropdown of the Overview page, record the value of Application (client) ID. You'll send this to us in a later step.
    6. On the top of the page, click Endpoints and record the value of the OpenID Connect metadata document. You'll send this to us in a later step.
    7. Navigate to Authentication in the left nav under Manage
    8. In the Implicit grant and hybrid flows section, enable the Access tokens and ID tokens checkboxes, then click Save
    9. Navigate to Token configuration in the left nav under Manage and click Add groups claim on the main panel
    10. Enable the Security groups checkbox
    11. Under the Customize token properties by type section, open the ID and Access dropdowns and select sAMAccountName for both. Click the Add button.
    12. Navigate to Manifest in the left nav under Manage. Locate the acceptMappedClaims attribute, change the value from null to true, and click Save.
      "acceptMappedClaims": true
    13. Click Default Directory | App registrations in the top breadcrumb then navigate to Groups in the left nav under Manage
    14. Create three new security groups that will be used for ProsperOps access: ProsperOpsViewerProsperOpsEditor, and ProsperOpsOwner (these group names are case-sensitive)
      • If you have a corporate group naming standard that necessitates a different naming scheme, you may use custom group names.
      • You may also use groups from your on-premise Active Directory domain. The Source column on the Groups page has a value of either Cloud or Windows server AD to indicate whether the security group is stored in Azure AD or is synced from on-premise Active Directory, respectively.
    15. Populate the three ProsperOps security groups created in step 14 with appropriate users. If you have existing users configured in the ProsperOps platform, you can reference the user and role mappings on our User Management page to understand current levels of access. Once identity federation is enabled, all ProsperOps platform users will be removed.

      Note: If a user is added to more than one group mapped to a ProsperOps role, the group granting the highest level of access takes precedence.
    16. For each of the three security groups, record the ObjectID (if using Azure AD) or sAMAccountName (if using on-premise Active Directory). You'll send these to us in a later step.

    17. Click Default Directory | Groups in the top breadcrumb then navigate to Enterprise applications in the left nav under Manage and click on the ProsperOps application (created in step 4)
    18. Navigate to Single sign-on in the left nav under Manage
    19. Click the Edit button in the Attributes & Claims box on the main panel
    20. In the Additional claims section, click the row with a groups Claim name. The Group Claims panel appears to the right.
    21. Expand the Advanced options section, enable the Filter groups checkbox, and configure:
      • Attribute to match: Display name (if using Azure AD) or SAMAccountName (if using on-premise Active Directory)
      • Match with: Prefix
      • String: ProsperOps
    22. Click Save
    23. In your email system, create an email distribution list (e.g. prosperops-users@mycomany.com) which will be used for all automated email notifications from the ProspserOps service (e.g. monthly summary emails, AWS account access alerts, etc.). If possible, we recommend you configure synchronization so the email distribution list always contains whatever members are in the three ProsperOps security groups.
    24. Email help@prosperops.com with the following:
      • The Application (client) ID and OpenID Connect metadata document gathered in steps 5 and 6 above (the data is not sensitive and does not require a secure transit channel)
      • The ObjectId or sAMAccountName of the three security groups gathered in step 16 above
      • The email distribution list created in step 23 above
      • The email address that should receive billing communications for your account (if not already configured)

    We'll configure your company for identity federation in our system and provide you with steps to test the experience once configured.