When you create an enterprise app in Azure AD and configure SAML-based single sign-on, Azure AD assumes that the application also supports SAML for sign-out – but as it turns out, not all apps do.
Continue »
When working with cloud services, you occasionally encounter two APIs that essentially do the same thing, but require different authentication or permissions. Such cases tend to pique my interest.
Continue »
By default, access to the Compute Engine metadata server is not limited to specific processes or users on a VM, even low-privilege processes can request service account credentials. Can we limit metadata server access to specific Windows users or processes?
Continue »
Service accounts play a key role in Google Cloud IAM, but they are easy to get wrong. If you’re not careful, you quickly end up with over-permissioned service accounts, accounts that are used across multiple applications, and service account keys being spread all across your environment.
Continue »
Libssh2 is written in plain C and runs on many platforms, including Windows. But to use the library on Windows, you have to build it first – and as it turns out, that is easier said than done.
Continue »
After creating a Windows VM on Google Cloud, users can use the Cloud Console or IAP Desktop to request login credentials. But what are the risks of letting users generate credentials, and is there a way to prevent them from doing so?
Continue »
In the last post, we looked at the risks of using local port forwarding and how it’s difficult to protect TCP tunnels in a multi-user environment. In this post, we take a look at how IAP Desktop protects its tunnels.
Continue »
If you are a frequent SSH user, then you’ll be familiar with local port forwarding. Creating tunnels by using local port forwarding is useful, easy, but also not without risks.
Continue »
In a company’s journey to the cloud, one of the topics that is important to sort out early is identity management. To do anything meaningful with Google Cloud, employees need to be able to sign in to the Cloud Console – but manually creating user accounts for each employee is rarely a good idea.
Continue »
Having covered the basics of certificate enrollment and relevant Windows APIs in previous posts, this post will look at how you can programmatically create a certificate signing requests by using the Certificate Enrollment API (CertEnroll).
Continue »
One thing certreq and the Certificate Manager MMC snap-in have in common is that they rely heavily on Windows’ built-in APIs for managing certificates, encryption, and keys. This post takes a deeper look at which APIs Windows provides for cryptography, key management, certificate management, and certificate enrollment.
Continue »
In the last post, we looked at how certificates, private keys, and certificate signing requests relate to another. In this post, we’ll look at three common ways to create a certificate signing request (CSR) which can then be submitted to a certificate authority (CA) for signing.
Continue »
Many of the protocols we use every day rely on certificates. The process to request and obtain a new certificate from a CA is called certificate enrollment. This post explains the basic concepts behind certificate enrollment.
Continue »
If your plan is to develop a tool or desktop app instead of a server-side application, the benefits of application default credentials are less obvious and reusing the user’s personal gcloud credentials instead might seem attractive. But there are some pitfalls.
Continue »
gcloud manages two sets of credentials, your personal credentials and application default credentials. Having two separate credentials might seem redundant and can cause surprises the first time you use one of the Google Cloud client libraries. But the two credentials serve different purposes.
Continue »
Google APIs use OAuth 2.0 for authentication and authorization. To call an API, you first have to obtain an access token for the right scope and then pass it to the respective API by using the Authorization HTTP header.
But the trouble with access tokens is that they are short-lived, and you somehow have to deal with expiring tokens…
Continue »
Once you’ve signed in on google.com, the
Cloud Console, or any other Google site,
your browser session remains valid for multiple days. Not being prompted to sign
in over and over again is convenient and at least in typical consumer scenarios,
the risk that comes along with keeping the session is limited.
Things can look different in a corporate scenario where users might have access
to sensitive data. Keeping sessions alive for 14 days (which is the default)
might seem a little risky and might not be in line with an enterprise’s idea
of security. G Suite Business and Cloud Identity Premium therefore allow you to
change the default session length
to a different period such as 8 hours. This setting applies to all Google services, not only GCP.