What is federated identity?¶
Federated identity allows one organisation or identity provider to authenticate a user for access to another service.
The cloud provider trusts the identity decision made elsewhere rather than maintaining a separate password for that user.
What this means in practice¶
In a federated arrangement, the user may authenticate through an employer, school, partner organisation or external identity platform. The cloud service receives an assertion or token confirming the user’s identity and permissions.
This can create several relevant evidence sources.
The identity provider may record the sign-in, authentication method, device and security checks. The cloud service may record the resulting session and activity. The customer organisation may hold role assignments, access approvals and account-allocation records.
What this may show¶
The same user may also have different identifiers across those systems. One log may record an email address. Another may use an internal object ID or federated subject identifier.
For investigators, identify the trust relationship. Which system authenticated the user? Which service accepted that decision? What identifier linked the two?
Where compromise is suspected, obtain records from both sides of the federation. Looking only at the cloud application may miss the original authentication event.
What this does not show on its own¶
The dangerous assumption is that the cloud provider must hold the user’s password or full authentication history.
Federation can also explain why disabling a password in the cloud service does not affect access. The real authentication control may sit with the external identity provider.
A federated login still does not prove who was physically using the account. Existing sessions, stolen tokens, compromised devices and shared access remain possible.
Key takeaway
Federated identity separates the authentication decision from the cloud service, so trace the user across the identity provider, the trusted service and the linking identifiers.