Id Administration (IdM) in Software program Corporations: A Advanced Migration Journey


Id administration (IdM) lies on the core of safety structure and processes in most software program firms. It’s chargeable for guaranteeing that solely licensed actors are allowed entry to helpful protected assets, together with our clients’ information.

For a number of years, our infrastructure relied on FreeIPA because the identification administration system of selection. It ruled person entry to digital machines by way of safe shell (SSH), facilitated third-party software logins, and served different use circumstances. Nevertheless, a number of causes led to its final elimination from our stack and substitute by different programs.

This text builds upon a earlier weblog publish, which centered particularly on the rework of our SSH entry administration. Right here, we doc the broader motivations for our IdM modifications, in addition to the particular steps and approaches the infrastructure staff at GoodData took throughout this advanced migration endeavor.

The Outdated Method

FreeIPA was launched into GoodData in 2012 in response to the rising measurement of our infrastructure and the next want for single sign-on, i.e., avoiding the necessity for customers to authenticate individually towards each inside service. With FreeIPA, engineers would merely must authenticate as soon as at the beginning of their day, acquiring a Kerberos ticket. All subsequent entry to inside internet functions would then reuse this ticket and be clear to the person.

One of many major use circumstances for FreeIPA in our stack was governing SSH logins to digital machines; we lined this in additional element in the earlier publish. FreeIPA additionally offered helpful parts protecting a number of different use circumstances. Notably, its NTP server offered a straightforward approach of time synchronization for the enrolled digital machines, whereas the bundled certificates infrastructure enabled SSL certificates administration for our inside companies.

The Shortcomings

Nevertheless, because the years went on, a number of points of the IdM setup primarily based on FreeIPA proved to be inadequate for efficient operations.

What we lacked probably the most was integration between FreeIPA and lots of the third-party programs we utilized. Whereas internally deployed internet functions utilizing httpd as a frontend had been simply prolonged with Kerberos-based authentication by way of FreeIPA, this didn’t maintain true for a lot of exterior companies, which generally solely present the SAML or OIDC strategies of authentication with identification suppliers.

The lacking hyperlink between FreeIPA and plenty of different functions we used meant {that a} unified method to person administration couldn’t be adopted. This resulted in sophisticated processes associated to person entry administration, in addition to onboarding and offboarding. For example, the staff chargeable for person administration needed to manually confirm if a terminated worker had been provisioned in quite a few functions, and manually take away their person account.

Working the FreeIPA service itself additionally prompted complications for our infrastructure staff on a number of events. We had replication arrange between FreeIPA servers in a number of completely different places, nevertheless it proved fragile in case a community subject was encountered. Moreover, the FreeIPA deployment itself offered a single level of failure; if a regression was launched by our operations, many of the engineers could be rendered unable to log in to the companies they wanted.

The Alternative

All of the aforementioned ache factors in the end led to a company-wide determination emigrate to Okta because the centralized IdM answer. This spelled an imminent finish to our utilization of FreeIPA, however on the identical time, created many new challenges for the infrastructure staff to resolve.

Most significantly, a direct one-to-one substitute of FreeIPA parts by Okta wouldn’t be attainable; for instance, Okta doesn’t present governance of SSH logins or SSL certificates administration out of the field. Due to this fact, whereas we’d transition to utilizing Okta because the central listing of person accounts, we must determine how precisely to make use of numerous open-source instruments and undertake completely different approaches for every particular use case we wanted to interchange.

We already lined the substitute for SSH login administration in the earlier publish. Now, let’s delve into how we approached the substitute of the opposite vital use circumstances.

Net Functions

The one facet of our IdM ecosystem that may be thought of migrated in a “one-to-one” trend was the authentication for internally deployed internet functions. The place we beforehand authenticated customers by httpd’s LDAP or Kerberos modules, we moved on to utilizing the mod_auth_openidc module as an alternative, with none giant architectural modifications being required.

Moreover, as implied above, an enormous benefit of migrating to Okta was additionally the help for single sign-on into a number of third-party functions. No extra guide administration of person accounts in every app!

Certificates

Changing the infrastructure of SSL certificates utilized by our digital machines, alternatively, required extra consideration. With FreeIPA, each enrolled server might get hold of an SSL certificates pretty simply utilizing certmonger. Nevertheless, this functionality would not be accessible with Okta.

Earlier than beginning to search an equal substitute, we took a step again and regarded the precise use circumstances we had for certificates. We recognized two distinct methods by which we utilized SSL certificates:

  • defending user-facing endpoints of inside internet functions;
  • machine-to-machine authentication between inside companies.

For the previous case, the answer was to make use of publicly trusted certificates issued by Let’s Encrypt. We solely wanted to determine the lifecycle and distribution of the certificates. In the long run, we chosen cert-manager operating in our service Kubernetes cluster to deal with acquiring the certificates (together with DNS validation), and a easy CronJob to retailer the certificates in our HashiCorp Vault occasion, the place all of the consuming machines can entry them.

Architecture Diagram
Structure Diagram

The Vault service additionally performed a key function in changing our machine-to-machine authentication mechanism; we opted for making a personal certificates authority (CA) to cowl this use case. Since all of our digital machines had already been built-in with Vault, it was then comparatively easy for some servers to acquire a shopper SSL certificates and for different servers to confirm it towards Vault’s CA.

Architecture Diagram
Structure Diagram

Time Server

Changing the FreeIPA-provided time server proved to be simple. Since most cloud suppliers present their very own time servers these days (for instance, Amazon has the Time Sync Service), we merely redirected our NTP configuration to make use of these as an alternative of FreeIPA.

The In-between

With an appropriate substitute for all of FreeIPA’s parts recognized, we centered on designing a rollout plan for the migration to Okta. We acknowledged that there must be an extended time window for the transition; we merely wouldn’t be capable of migrate all the customers and software integrations from FreeIPA to Okta on the identical time and with out introducing an unacceptably lengthy downtime for the staff.

To offer a bridge between Okta and FreeIPA, and to allow a clean swap of 1 use case after one other, we determined to introduce a synchronization mechanism between Okta and FreeIPA. We utilized our pre-existing inside software known as freeipa-manager for this goal, which supported managing FreeIPA entities by their YAML representations saved in a Git repository. Initially, we created accounts for all customers in Okta after which prolonged this software by including help for creating customers primarily based on a response from Okta API.

This transition interval was not best for the staff, since they needed to keep in mind two separate passwords for each of our IdM programs, in addition to needing to maintain monitor of which functions had been authenticated by which system. We centered closely on cross-team communication to make this time as painless as attainable for all of the customers concerned.

The Conclusion

All in all, our migration from FreeIPA to Okta took barely lower than two years, beginning in early 2021 and ending with eradicating the FreeIPA servers themselves from our surroundings within the second half of 2022.

It was an immense studying expertise that required extensive cooperation between the corporate’s departments, in addition to studying the assorted deeper internals of the authentication applied sciences concerned. On reflection, we are able to confidently conclude that this huge change was properly well worth the effort, bringing our infrastructure safety and the associated person expertise to the next stage.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Stay Connected

0FansLike
3,912FollowersFollow
0SubscribersSubscribe
- Advertisement -spot_img

Latest Articles