What does federated mean in search, identity, and databases?

Federation, in the highest-level definition, is a group of entities that are independent yet united under a central organization. Think of it in terms of politics: It’s like a collection of towns that have autonomy over how they rule themselves individually but agree to a certain set of standards and policies for the overall state or country they belong to. When it comes to technology, federation has a similar definition but relating to independent systems rather than governments.

Federation has become increasingly important as the internet dips its toes into every facet of our lives. Enterprise companies used to provide all of their own technical services—from databases to identity management. These days, those technical services are commonly done by third-party SaaS companies. For companies with irons in a lot of little SaaS fires to operate smoothly, there needs to be a uniting force between these third-party systems. Thus, the concept of federation was introduced.

Federation in technology can apply to a lot of different systems, but we’re going to focus on three of the most common use-cases: federated search, federated identity, and federated databases.

Federated search: perusing many sources at once

Federated search works by taking in one query from a user, searching multiple sources, then returning results compiled into a single format to the user. You can think of it as a really powerful manager organizing many separate processes at once, then presenting a beautifully polished final product.

In more detailed terms, federated search has seven main steps:

1. The user enters a search query.
2. Federated search transforms the query into a standardized format.
3. Federated search broadcasts the query to all related resources, including web pages, databases, etc.
4. The data resources send back results from the query.
5. Federated search de-duplicates the results.
6. Federated search restructures the results into a unified format.
7. The results are presented to the user.

The concept may sound similar to distributed search, where multiple computers conduct a search simultaneously. The biggest difference between the two is that federated search acts as the centralized force behind this inquiry. It’s in charge of formatting the query to send to other systems, de-duping the results, then formatting them into a simplified format for the reader.

To get a clearer idea of the benefits of using federated search, imagine a search engine. There are many websites, databases, and records that our federated search engine could send a query to. In order to serve the best results, our search engine would try to guess the user’s intent in the search. If a user searched “black dog” in the federated search, it would need to figure out if the user wanted photos of a black dog, search results for breeds of black dogs, or the Led Zeppelin song Black Dog. Based on the user’s previous search history (and a myriad of other factors), our federated search can make an informed guess.

Federated identity: authorize once for many apps

Federated identity works by sharing a user’s verified authorization across many applications using a set of predefined policies for managing the identity. Federated identity allows a user to access all of the data and apps across multiple systems through one interface without needing to log in to each system individually.

With federated identity, each system can be in its own domain and have its own set of security protocols. The important part is that they can all still communicate via the centralized federated identity.

‍
You might be thinking that the concept of federated identity management probably sounds similar to single sign-on (SSO). You’re not wrong: SSO is a subset of federated identity. In fact, SSO wouldn’t exist without federation. SSO works by having a user from an org sign in to a single application once, then that authorization is shared across systems used by that org. This is really popular with modern companies that use a lot of SaaS apps.

Having employees spend time signing in to work management apps, secure messaging apps, cloud drive apps, etc., ends up wasting a lot of time. Instead, using an identity management system to handle user authorization, then propagating that authentication to all apps the user needs (both internal and external) not only saves the user time but also provides a far better experience. Plus, it’s more secure because the user doesn’t have to remember a long list of complicated passwords.

Common technology used for federated identity:

• SAML (Security Assertion Markup Language) – Publicly available standard for authentication and authorization between an identity provider and a service provider (think: identity management and a SaaS app).
• OAuth – Publicly available standard for sharing data between apps without giving away passwords.
• OpenID – Publicly available standard for authenticating users between relying parties via third-party apps (logging in to apps via Facebook is a similar idea, but they use their own protocol called Facebook Login).

Federated databases: big systems working together

Federated database systems work by connecting disparate databases together with a unifying user interface. Similar to how federated search works, federated databases act as a type of wrapper around multiple databases that operate independently. Each database can structure its data in whatever way it wants and use any query language. The key with federated databases is that they all know how to communicate with the centralized database.

The federated database is in charge of taking a single query from a user, formatting that query to whatever query language each database is using, then taking the results and reformatting them into a uniform result for the user.

Federated databases are a popular way to “merge,” though no databases are actually merging. Instead, all data stays in its own database and in its original format. Data migrations and merges are incredibly complicated processes, so avoiding them is generally a favorable solution.

Federated databases are great for situations where a company reformats its data structure but doesn’t want to port over the old data. A federated database will help all of the data work uniformly with one user interface. Another scenario where a federated database is useful is when a company is bought out and needs to merge data with the parent company or product.

Conclusion

Federation — whether in search, identity management, or architecture — abstracts implementation details by providing a centralized, uniting force for different, autonomous systems to all work together. With these details hidden from the final experience, the user enjoys simple, smoothly interlocking applications.