Updated: May 16
An Identity Provider (IdP) is a system or service that manages and provides authentication and authorization services to users or entities within a network or system. It acts as a trusted authority that verifies and asserts the identity of users and issues authentication tokens or claims that can be used for accessing resources or applications. The primary function of an Identity Provider is to authenticate users and generate security tokens that contain information about the user's identity. These tokens are then securely passed to service providers or applications to enable access. The IdP is responsible for establishing trust between the user and the service provider by verifying the user's identity and ensuring they have the necessary permissions to access the requested resources. Identity Providers are commonly used in Single Sign-On (SSO) scenarios, where a user logs in once to the IdP and gains access to multiple applications or services without the need to authenticate separately for each one. This simplifies the user experience and improves security by centralizing identity management.
In this article I will provide you a maximum overview of an Identity Provider (IDP) from the perspective of Cloud-, or Hybrid-Computing. This information should provide you only an overview and not a technical documentation.
What is an Identity Provider used for?
Identity provider is responsible for validation of an user/device identity used for different login processes, or system access.
So basically, IDP is responsible of Identity and Access Management for a specific application/user scope.
There are millions of different IDPs on the market right now, so I will group all of them into three groups:
A local IDP does not required any kind of connectivity and is managing its identities in the local User directory.
Here is the local User directory of a standard Windows OS.
This is a typical User management of a local application / device.
On-Prem IDP is located in your local DataCenter. This is complex server infrastructure environment, which is operated by your local team of administrators and is hosted on a bunch of servers.
Cloud IDP is a service which is located in the datacenter of a Cloud-Service-Provider (CSP) and is operated and hosted by CSP. All Cloud-Services are mostly based on per user/device subscription. You just need to pay monthly fee and use the service.
How to connect application, or service to an IDP?
Different applications support different IDPs. App to App and IDP to IDP, integration may be more or less complicated.
Local application, or service
Most applications have their own User-Directory with local permissions and don’t need to be connected anyhow. Application administrator is responsible to User-Life-Cycle management.
Every user and his permissions needs to be created manually by application administrator.
If your application is located in your datacenter, it can simply access On-Prem IDP by using LDAP queries, or similar mechanism. Username and password are saved in your On-Prem IDP and not in the application itself.
If your application is hosted in a different data-center and is not connected to On-Prem IDP, there are several scenarios how to connect it.
You can configure a VPN tunnel from your cloud-application, which is located in a Trusted Cloud DC, directly into your environment and allow access to your On-Prem IDP.
If your Cloud-Application has a fixed and known IP address range, you can simply forward required ports to your On-Prem IDP and connect your application.
If your application is in the Cloud and you have a Cloud-IDP you need to create a trust between the application and Cloud IDP.
This trust is based on a certificate authentication and requires exchange of certificate information between the application and your Cloud IDP.
This process is called “SAML / OAuth / ADAL connection” depends on application and operating system.
How to connect IDP to another IDP?
In the modern enterprise architecture nearly all services and application are connected to an own On-Prem IDP and has no direct connection to customer environment.
All services / application requires different user/device information and have different naming for them.
Information like “username” can be also called: SamAccountName, UserPrincipalName, Username, User etc. and all of them are managed by IDP.
Something needs to translate this different IDP information to fit your On-Prem IDP so that all users from your organization can access all required applications and services without any additional authentication and user management.
This translation service is called.
It is using SourceAnchor attribute from your On-Prem IDP to match user/devices located in different application/services to your local user/devices.
Federation service is using Claims (=attributes) and Claim “translation” rules to match user/device information between different IDPs.
If you have additional questions, just reach out to me.
I hope you have enjoyed this demystification article.
If you have any questions just leave me a feedback.