The principle of least privilege states that we should grant users just enough access to carry out everyday activities, but no more. But what about the occasional case where a user does need privileged access, maybe to handle an incident or perform a rare configuration change? This is where just-in-time access can help.
Continue »
Before we deploy an application to Google Cloud, we typically want to test it locally. If the application uses Google Cloud APIs, then we somehow need to ensure that the application can authenticate. We could use a service account key for that, but there’s typically a better way.
Continue »
Previously, we explored two ways of authenticating to Google Cloud using Kerberos and NTLM credentials. Both ways involved authenticating to AD FS using Integrated Windows Authentication, and then using workload identity federation. But there’s a third way that we haven’t cover yet – and it involves using the SAML HTTP-POST binding.
Continue »
When an application needs to access Google Cloud APIs, it needs credentials. On Google Cloud, we can attach a service account to the underlying compute resource to let the application obtain credentials. On AWS and Azure, we can achieve something to the same effect by using workload identity federation. But what about on-premises?
Continue »
Workload identity federation supports OpenID Connect, so it should be compatible with AD FS. But until recently, workload identity federation didn’t work with AD FS-issued access tokens – only ID tokens worked properly. What was the issue there?
Continue »
Some Google Cloud APIs don’t support service accounts and require us to use domain-wide delegation. But using domain-wide delegation doesn’t mean we have to use service account keys.
Continue »
Workload identity federation lets us impersonate a Google Cloud service account by using credentials from an external identity provider. That’s a useful and powerful feature, but there are some things to watch out for.
Continue »
By using certificate-based authentication, we can let a Google Cloud service account authenticate to AD FS without having to manage any client secrets.
Continue »
A common way to let an application authenticate to KeyCloak is to use a client ID and secret. But when the application runs on Google Cloud, we can do better.
Continue »
Using Integrated Windows Authentication (IWA) to authenticate to AD FS not only works for OAuth. We can also use IWA to get SAML 2.0 assertions.
Continue »
When an application needs to authenticate to AD FS, we don’t have to use a client secret. Instead, we can let the application use its existing Kerberos or NTLM credentials to authenticate.
Continue »
In the last post we looked at how to set up a trust policy and role in AWS so that we can use a Google ID token to authenticate to AWS. But how do we actually use this in C#?
Continue »
By using workload identity federation, we can let applications use AWS credentials to authenticate to Google Cloud. That’s useful if we have an application that runs on AWS and needs access to Google APIs. But what if we are in the opposite situation, where we have an application on Google Cloud that needs access to AWS?
Continue »
Most browsers support client certificates for mutual TLS authentication. But what is really being authenticated here, the end user, their device, or both?
Continue »
By default, installing AD FS requires domain admin access to Active Directory. But it’s possible to deploy AD FS in environments where we don’t have these privileges, like Google Cloud’s Managed Service for Microsoft Active Directory.
Continue »
When an application running on AWS needs access to Google APIs, we can use workload identity federation to let the application use its AWS credentials to authenticate to Google APIs. Unfortunately, the C# client library doesn’t support that yet, but we can fill that gap.
Continue »
Instead of using OAuth and access tokens, AWS uses request signatures to authenticate API requests. Typically, we can let libraries do the request signing for us – but sometimes we have to do it ourselves.
Continue »
By using workload identity federation, we can let applications use Azure credentials to authenticate to Google Cloud. That’s useful if we have an application that runs on Azure and needs access to Google APIs. But what if we are in the opposite situation, where we have an application on Google Cloud that needs access to Azure APIs?
Continue »
When an application running on Azure needs access to Google APIs, we can use workload identity federation to let the application use its Azure credentials to authenticate to Google APIs. Unfortunately, the C# client library doesn’t support that yet, but we can fill that gap.
Continue »