MongoDB Cloud and Azure SSO with Okta

File:MongoDB Logo.svg - Wikimedia Commons

Two blog posts ago I blogged about #ChaosDB, which was concerning CosmoDB.

Somehow in bright mind (at 0630am) I successfully switched CosmoDB to MongoDB. After my blog post got some attention a got a Twitter notification that I had wrote wrong DB all the way in my blog.

So I just want to say, there is nothing wrong with MongoDB and it wasn’t part of the this #ChaosDB mess in any way.

So as my sincere apology I will write about Azure AD SSO to MongoDB Cloud. It uses Okta for SSO and that is also down my alley, so I give it a shot.

So first the limitations considering sso

So you cannot use SSO for database users for that you have to enable Azure AD Domain Services. MongoDB will pull the users and published claims from thru ldap.

Then to Azure AD users SSO and integrating that with portal.

MongoDB has excellent instructions how to perform IdP federation

And there is also help from MSFT side from

I followed MongoDB instructions (because as of now I haven’t ever used MongoDB, for everything there is the first time) and it was precise, but had to pics, so I took some and will follow them thru in here.

First I made my self an free MongoDB account. You can sign-in with Google, but there is also manual option.

  • Then I logged to and browsed for MongoDB from the gallery.
  • And pushed Create, easy for now.
  • When app was provisioned, I opened it and select Single Sign-on.
  • And SAML as method.
  • Then to MongoDB’s side. I choose the free version as this in only for demoing purposes.
  • And as MSFT supporter and North European I chose Azure in Ireland.

  • First time ever I saw MongoDB Atlas control panel, there was a checklist to show what can be done.
  • Then I got information on my cluster being created, the page and the layout was precise and clear, no fuzz, which is good.
  • While my DB was provisioning, I decided to browse around and found MFA settings. Microsoft is missing, but Google authenticator QR-code can be scanned to Microsoft Authenticator as well, only as OTP though, no Push notifications.
  • And enough waiting, went to Federation Management and chose Identity Providers. And populated Issuer URI and SSO URL with generated placeholder values.
  • Then back to Azure AD to generate SAML configuration so I could download Certificate which is needed to publish MongoDB’s side of federation.

Then back to MongoDB and uploaded the downloaded certificate.

  • Then I was able to generate the metadata needed to get the config running in Azure.
  • Back to Azure and selected Upload Metadata file.
  • And I have my config done.
  • Was going to try Automatic Provisioning, but didn’t work. Excellent feature, hopefully in the future MongoDB will support this.
  • When You have done your configs, you can to test the sso setup. You will find this one from the same page where you make the metadata upload.
  • For testing you can use logged in account or other one. It will test the application based on our rights and attributes. It will give a clear picture of what is happening if something isn’t working.
  • From properties you can choose will the app be available for all users or does it have to assigned. And will it even be visible to users any users, assignment or no.
  • When assignment is required, you will to to Users and groups to add a user.
  • Now if you go to and login with your Azure AD creds, you will see MongoDB published.

  • And you could login with your Azure AD credentials to MongoDB. I don’t continue any longer with this as I don’t have verifiable domain name to add, so I really cannot try SSO with MongoDB.
Then I will continue with a bit of Identity Protection Microsoft style. Thanks MongoDB, I’ll be seeing you again. You can assign roles for the users with PIM. Quick recap on Privileged Identity Management.

  • Provide just-in-time privileged access to Azure AD and Azure resources
  • Assign time-bound access to resources using start and end dates
  • Require approval to activate privileged roles
  • Enforce multi-factor authentication to activate any role
  • Use justification to understand why users activate
  • Get notifications when privileged roles are activated
  • Conduct access reviews to ensure users still need roles
  • Download audit history for internal or external audit
  • Prevents removal of the last active Global Administrator role assignment

You can allow user or a group to a role, except the following ones.

Classic subscription administrator roles

You cannot manage the following classic subscription administrator roles in Privileged Identity Management:

  • Account Administrator
  • Service Administrator
  • Co-Administrator

Active means that user doesn’t have assign it and Eligible means that user is entitled to this assignment and can take the power given.

  • When you to add the assignment, you will be facing the settings below. You can choose a role for the user, I chose Application Developer.
  • And then the assignment type with a time for it be valid. Permanent in kind of explaining itself.
  • And now we can see the user and rights under active assignments.
  • Also a really nice feature is User consent, you can allow a user or a group of users to Approve (consent) and app, the can be just users, no need for admin rights.
  • And Self-Service, with this one you can let users request access to published app and add them to a group after approved.
  • And of course application based Conditional Access, create rules directly from the published app, how easy is that.

So as a conclusion, there has been a lot of new stuff coming to Azure with identity protection and SSO. In this article I just named a few, I will be blogging about identity protection and things including Identity (that’s a lot, like all) so there will be more an Entitlement Management and PIM in my blog.

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *