If your organization uses Amazon Web Services (AWS), you might be asking yourself how to best secure access. Here's a brief overview of your options, and a look at when UserLock SSO for AWS is a good fit.

When single sign-on (SSO) first came on the scene in the 1990s, most people saw it as a way to make life easier for employees at large organizations by allowing them to log into multiple applications with a single credential. And today, this aspect of SSO is still central.

But over time, two less obvious benefits of SSO are becoming even more important: authentication security and user monitoring.

The driver behind all three, of course, is the explosion of applications. One far beyond what the inventors of SSO probably had in mind. The problem is, the more applications you have, the harder they are to manage. That in and of itself makes them less secure.

For one, it's a big challenge for the IT team to securely monitor users across multiple applications. And the problem only gets worse as employees try to cope with multiple credentials and use risky workarounds.

So, while offering users just one SSO credential solves these problems, it's only worth it if IT can properly secure that credential — now a single point of vulnerability.

Of course, properly securing the credential is key. But before we dive into that, let's back up. Do we understand the core problem SSO is trying to solve? Fundamentally, SSO today is an answer to the need to securely manage the bewildering complexity of modern application delivery.

We have too many applications in too many places, with too many separate logins.

The first layer of these applications is the traditional on-premise and legacy applications organizations have been using for years, authenticated via a directory service such as Microsoft Active Directory (AD). Of course, your users need to enter their Active Directory credentials to log onto their machine, long before they can launch a browser and go to their AD applications or other Cloud SaaS apps.

Next up are the standalone cloud SaaS services organizations depend on such as Salesforce or Slack. Reconciling these is a big enough job, even without factoring in the dramatic expansion of cloud platforms over the last decade. Each one might require numerous credentials to access applications run by the customer as well as the many on-platform services offered through it.

The best-known illustration of this last example is Amazon Web Services (AWS). The vast platform encompasses multiple Amazon services plus customers’ applications and virtual servers. Anticipating the difficulties this generates, Amazon provides SSO through AWS IAM Identity Center (formerly AWS SSO until 2022). This makes it easier to provision SSO access to Amazon applications while also, importantly, allowing:

• Integration with a range of third-party cloud platforms through SAML 2.0 (Microsoft 365, Salesforce and Google).

• Integration with several third-party identity providers (IdPs) such as Okta, OneLogin, and Ping Identity.

In theory, Amazon's SSO keeps things simple. If your organization is cloud-centric and is heavily invested in Amazon, using AWS IAM Identity Center can work just fine. Of course, you need to make sure your IdP has an AWS integration. And, depending on your identity and access management (IAM) needs, even cloud-centric organizations can gain more flexibility by using a third-party SSO provider.

But what about the many organizations that are not cloud-centric? Many primarily use on-premise applications authenticated via AD. And for Active Directory environments, solutions like AWS IAM Identity Center just aren't a good fit.

Your users still need more than one set of credentials: their Amazon AWS credentials AND their AD credentials. We like to call this "pseudo-SSO," because it still uses two sets of credentials. There's no "single" in that sign-on!

The easiest way to accommodate an on premise AD infrastructure with Amazon AWS is to use a dedicated on-premise SSO solution such as UserLock. With UserLock, your users can use just one set of credentials, their Active Directory credentials, for access to AWS and AWS-supported apps.

You'll notice that most of the discussion around SSO focuses on convenience. That is, avoiding the need to have multiple credentials for different platforms.

This downplays the issue of security. As we noted earlier, security is becoming more and more of an issue when implementing SSO.

In some ways, configuring SSO is the easy part. The last part of the puzzle is always implementing SSO securely.

Using AWS IAM Identity Center or a third-party IdP SSO requires that you:

1. Trust the security controls on those platforms, and

2. Will learn or hire someone with the skills to use them competently.

As with all cloud platforms, Amazon AWS operates based on a shared security model. The provider is responsible for the underlying security of the platform, but you as the customer must secure your resources and data.

So, let's look at this from the point of view of an IT manager. Using AWS IAM Identity Center to do this means you now have another system to manage. This creates room for misconfiguration (excessive permissions given to end users), and mismanagement (weak user housekeeping).

The same problems arise when using an external IdP. This is in addition to some of the other IdP disadvantages such as the risk of vendor lock-in, higher running costs, and the fact that not all applications or services might be supported.

The security limitations are an unavoidable aspect of SSO. Any system that grants access to numerous services through a single credential makes that credential a weakness if it falls into the wrong hands or is misconfigured. This is why credentials have become a major target for attackers, who know that compromising even one with the right privileges can lead to a major compromise.

If your organization needs to meet tight compliance or regulatory requirements (or just wants to be secure), simply trusting an IdP for SSO is a non-starter.

Protecting your critical on-premise applications requires absolute certainty and visibility. UserLock is one of the few solutions to offer secure on-premise SSO for organizations that must meet requirements that authentication stays on-premise in Active Directory.

When you implement SSO in this way, you can better:

• Guarantee in-house control and oversight over applications and users.

• Extend your organization's existing investment in Windows AD without the time and expense of migrating users to a new SSO platform.

• Set up SSO with Amazon AWS as well as a wide range of SAML-based cloud applications.

• Configure SSO with fine controls over extra security layers such as multi-factor authentication (MFA) and access restrictions based on session type and contextual factors.

Configuring UserLock SSO with AWS is straightforward.

The first step to connect UserLock SSO and Amazon AWS SSO is to enable UserLock as an external identity provider using the AWS console. Once complete, access to AWS is assigned to each authorized user.

In the UserLock console, you'll want to select AWS as the platform to be configured by navigating to SSO configuration. The AWS SSO certificate and URL metadata that points to AWS are added to UserLock. Don't forget to make sure that the SAML certificate establishing AWS trust is up to date.

For a more detailed overview, head over to our documentation on configuring UserLock SSO for AWS.

Once you configure UserLock SSO for access to AWS, you can go one step further. Amazon AWS offers a vast catalog of SaaS applications available via AWS SSO.

UserLock SSO links up with AWS SSO behind the scenes, so your users can access any SaaS application configured in AWS.

Read more about how to configure UserLock with AWS SSO.

UserLock SSO offers several benefits to end users and admins alike.

Users benefit from the simplicity of SSO.When your users are connected to a domain machine, when they access the SaaS application, they don't need to re-enter their credentials. They'll use the same authentication token as in Active Directory.

This helps improve the user experience, for sure. It also reduces password sprawl. Instead of having to manage a separate Amazon credential, users gain access to both the AWS platform and AWS-supported apps using their standard AD login.

And since this happens without extra passwords to remember or login screens to navigate, it doesn't get in the way of productivity. It also keeps complexity out of sight, away from the user.

IT teams can manage user identity through AD in the same way they always have, and can provision Amazon AWS and other cloud user access through the UserLock console.

Importantly, the same familiar security controls apply. As with other types of access, this includes MFA (authenticator apps, push notifications, or hardware tokens), which can be customized for specific types of connection or login conditions.

Admins can see how MFA is being applied, easily track failed authentication attempts (which might indicate an attempt to breach security) and if necessary, disable MFA access for individual accounts.

The big advantage of UserLock is that you can apply the same MFA and access controls across RDP, VPN, IIS, and SaaS sessions. Any organization that wants a single solution to manage access restrictions will find value, including those that:

• Are heavily invested in an on-premise environment but want to enable hybrid access to Amazon AWS and other cloud platforms through SSO.

• Operate in tightly regulated environments where detailed auditing is essential and trusting a cloud provider for IAM is not an option.

• Want to boost SSO security with granular MFA, concurrent session restrictions, and other monitoring controls not offered by Amazon AWS IAM Identity Center.