Overview of Authentication Federation
The SiX IDaaS & IAM Identity Application provides a fully OIDC/OAuth2-compliant Identity Provider (IdP) out of the box. This IdP concurrently supports SAML2, allowing clients to authenticate using either OIDC/OAuth2 or SAML2, depending on their specific integration requirements.
Developers can easily deploy a brandable and highly configurable IdP with minimal setup effort.
The platform is architected to decouple authentication from authorization, enabling flexible integration patterns and a clean separation of concerns. It also supports Federated Authentication, allowing the IdP to delegate user authentication to external identity providers.
Protocol Agnosticism
From a client's perspective, it can act as either an OIDC/OAuth2 or a SAML2 client to interact with the SiX IDaaS & IAM IdP, regardless of how the IdP handles the underlying authentication internally.
Enhanced Security
Following federation, your IdP users can benefit from Multi-Factor Authentication (MFA) and granular consent control for personal information sharing. Learn more at: Overview of Data Security & Privacy.
Delegated Authentication
Authentication federation refers to the process of delegated authentication. When the IdP within a SiX IDaaS & IAM tenant receives an authentication request, it delegates that request to a pre-configured external identity provider.
Why Federated Authentication Matters
Seamless Integration and Unified Identity
When deploying software—whether on-premises or as a SaaS solution—customers prefer utilizing their existing corporate accounts (e.g., credentials from Active Directory) rather than managing separate logins for every system. However, software still requires a reliable authentication mechanism to function, typically assigning each user a unique internal ID.
If every third-party application relies on its own isolated authentication system, data silos emerge. The same user ends up with different IDs across various systems, making end-to-end integration cumbersome. Without a unified identity, linking user data across platforms becomes a significant technical challenge.
The Solution: Federation with a Corporate IdP
By federating authentication with the customer’s existing IdP (such as corporate Active Directory), you resolve these identity conflicts. Here is the typical workflow:
- User Authentication: When a user accesses your software, they are redirected to their familiar corporate IdP for login.
- Global User ID: Upon successful authentication, your system receives a token containing the user’s Global Unique ID (e.g., an immutable object ID).
- Local Account Mapping: Your software creates a local user account, assigns an internal ID, and links it to the Global ID provided by the IdP.
- Seamless Integration: In end-to-end integration scenarios, the Global User ID serves as the consistent key to unify data across all federated systems.
Strategic Benefits
By implementing federation with SiX IDaaS & IAM, you provide your customers with:
- ✅ Single Sign-On (SSO) – Users log in once to access all integrated systems.
- ✅ Enhanced Security – Centralized enforcement of MFA and security policies.
- ✅ Data Interoperability – Elimination of silos by linking user data across platforms using a universal identity.
Typical Federation Flow
🔐 Federated Identity Provider Options
| No | Federated IdP | Description | Typical Use Case | Credential Location | Pass-through SiX IDaaS & IAM? |
|---|---|---|---|---|---|
| 1 | None | No federation | Local tenant-managed users | SiX IDaaS & IAM | Yes |
| 2 | OIDC IdP | Platform acts as OIDC client | SSO with external OIDC providers (Azure, Google) | Federated IdP | No |
| 3 | SAML2 IdP | Platform acts as SAML2 SP | SSO with external SAML2 providers (Okta, AD FS) | Federated IdP | No |
| 4 | HTTP/HTTPS IdP | REST API-based authentication | Custom integration with legacy corporate directories | Federated IdP | Yes |
| 5 | Custom IdP | Forwarded encrypted auth flow | Advanced custom or proprietary identity systems | Federated IdP | No |