What Is an IdP?
IdP is an abbreviation for "Identity Provider." It is sometimes written in all capital letters as "IDP."
An IdP typically performs authentication (for example, a user logging in by entering an ID and password) on behalf of the various cloud services that would otherwise handle it themselves, and then provides the authentication information to those cloud services.
There are two main scenarios in which an IdP is used.
IdP in Standard SAML Authentication
SAML is an abbreviation for "Security Assertion Markup Language," an international standard widely used for exchanging authentication information as XML documents. For more details on SAML authentication, please refer to the article below.
Related article
Glossary: SAML | Security Assertion Markup Language
In SAML authentication, the IdP acts as an intermediary between the cloud service and the user, providing the authentication information. This role is typically fulfilled by single sign-on services or federation services. In practice, it is used by SAML-compatible single sign-on products such as our own product, TrustLogin (formerly SKUID), as well as by SAML authentication integrations using Active Directory Federation Services (ADFS) or Azure AD.
SAML-Based External IdP Authentication
External IdP authentication is used when an organization introduces a single sign-on product, in order to preserve its existing ID management structure and avoid increasing administrative workload.
When introducing a single sign-on product, the standard approach is for the single sign-on product's ID to become the organization's master ID, with other services' IDs then linked to it. However, for companies that already have an established management structure built around a different master ID, changing that existing structure in order to introduce a single sign-on product would require too much administrative effort.
An external IdP is used to introduce single sign-on without making the single sign-on product itself the master ID. Instead, the ID the organization already uses as its master (for example, G Suite, Azure AD, or Salesforce) remains the master, and the single sign-on product is linked to that master.
As a result, when the single sign-on product is introduced, the master ID does not change for users. They can continue using the same master ID as before to newly log in to the single sign-on product, and from there use single sign-on to access the various cloud services.
(Example using G Suite as the IdP)
For information systems departments, this makes it possible to introduce a single sign-on product without changing the existing management structure, greatly reducing the administrative workload and cost of implementation and operation.
For users, meanwhile, they gain access to new functionality without having to change the ID and password they already use, so there is no need to "memorize a new ID and password." This also benefits information systems departments by avoiding the confusion caused by distributing new IDs and passwords, as well as the flood of password reset requests that typically occurs when new IDs are issued.
Choosing the Right IdP
Single sign-on products that support cloud services are also known as "IDaaS" (Identity as a Service). According to a US research firm, the IDaaS market is projected to grow at an annual rate of 36.5% between 2017 and 2021.
Related article
The IDaaS market is growing at an average annual rate of 36.5%
The authentication provided by single sign-on products includes SAML authentication. As a result, single sign-on vendors, acting as "IdPs," will handle an increasing share of authentication going forward. In other words, many companies will come to depend on an IdP for their cloud authentication. This makes choosing a trustworthy IdP extremely important.
Below are three points for evaluating trustworthiness.
1. It Is a Trustworthy Company
For a contract to be honored and a service to be provided stably, what matters even more than which features a product does or doesn't have is whether the service provider itself can be trusted. For example, companies that fall into any of the following categories carry higher risk.
- The company's financial condition is unstable, or it is operating at a loss
- The company is small (operated by a very small number of people)
- The company has little track record in the information security field
- The company has no track record, or only a limited track record, of operating cloud services
2. Uptime and SLA Are Published, and the Company Undergoes External Audits
Because this is a service responsible for authentication, it is naturally expected to run stably 24 hours a day, 365 days a year. It is therefore preferable for the service's uptime status to be published, and for its uptime to exceed 99.9% (roughly 8-9 hours of downtime per year). It is also preferable for the service's SLA to be clearly documented.
Another criterion is whether the company undergoes external audits and holds relevant certifications. One certification that supports the operational trustworthiness of a cloud service is the SOC (Service Organization Control) report.
3. Comprehensive Support
Because this service is used to authenticate employees when they use cloud services, support is extremely important whenever a problem occurs or something needs to be confirmed. The following three points are worth considering.
1. How to Contact Support
For many cloud services, the only way to get support is through an "inquiry form" or "email." This is not a problem for lower-priority services, but when it comes to "cloud service authentication," the priority is extremely high, and it is preferable to be able to quickly contact a support representative and get a response.
For this reason, check whether support is also available through channels such as "chat" or "phone," in addition to the methods above.
2. Support Escalation Path
To resolve issues quickly, what matters is how fast you can reach someone knowledgeable within the product vendor. Typical product support generally follows an escalation order like this:
- First-line support
- The vendor's general inquiry desk. Responds based on past issues found by searching a support database.
- Second-line support
- Staff in the vendor's support department. Also responds to issues not listed in the support database.
- Third-line support
- The vendor's development staff. Handles problem resolution, including fixing the program itself, when the issue lies in the program.
Note that for overseas vendor products, first-line support is often provided not by the vendor itself but by a reseller, which can make problem resolution take longer (and time zone differences with overseas vendors can also delay responses). If you are considering a service, it is preferable to confirm how inquiries are escalated.
3. Language
For products from Japanese vendors, both the vendor and the customer communicate in Japanese, so language is not an issue. However, with support for overseas vendor products, responses to issues escalated to the vendor may come back in English. You need to confirm whether the domestic reseller in Japan will translate each English response into Japanese, or whether you will simply be handed the English response as-is.
If the reseller handles translation, there is a risk that "the reseller may translate incorrectly." If you translate it in-house, the challenge becomes "needing staff internally who can correctly read technical information in English."