Mainstream adoption of single sign-on (SSO) is transforming application access for today’s digital workers. Instead of authenticating to applications and services using lots of different credentials, SSO makes it possible to hide the complexity behind a single password and user name. One cloud service where SSO is increasingly in demand to boost access security is the e-signature platform Adobe Acrobat Sign (formerly Adobe Sign).

The ability to send, receive, and track signed documents, a workflow almost as old as work itself, was overdue for an upgrade. Now, cloud platforms like Adobe Acrobat Sign do the same job digitally. And organizations and individuals alike are using the service more and more.

Offered as an Adobe Cloud service and managed through the Adobe Console, Acrobat Sign offers customers access to a range of complex capabilities, including identity verification, secure document storage, password protection and expiry, and tight integration with Adobe’s in-house PDF document format as well as Microsoft Word.

Organizations are eager to do business faster, which means rolling out Acrobat Sign to a wider range of employees. One of the simplest ways to enable this is through SSO. Employees benefit from SSO for Adobe Acrobat Sign because they need only remember one password. This makes for a better user experience and helps productivity. And administrators gain too. For one, they can limit the number of user credentials floating around, which in turn lowers the possibility that one might fall into the wrong hands.

Importantly, SSO also makes it easier to impose security policies on access to cloud services, including Adobe Acrobat Sign. For example, admins can enable multi-factor authentication (MFA) or enforce password policies. Despite these benefits, however, configuring and designing SSO can still be complex when it comes to individual applications like Adobe Acrobat Sign.

Although SAML 2.0 has made it easier to set up authentication between multiple services such as Adobe Acrobat Sign, the technology can still throw up hidden issues that vary unpredictably from organization to organization.

In the majority of organizations, employees must use a mixture of on-premise and legacy applications in conjunction with third-party software-as-a-service (SaaS) based in the cloud.

For SSO, knitting these different realms together can be a deployment challenge that creates additional complexity.

For example, on-premise and legacy applications are unlikely to be compatible with SSO or the security technologies such as MFA that must be implemented at the same time to secure it. Even some cloud applications might still require integration through APIs. Inevitably, every workaround and extra integration increases complexity and overhead.

Complexity, of course, is bad news because it generates less certainty when it comes to security.

In the rush to embrace cloud services, it is easy to forget that organizations can’t simply abandon their on-premise applications. Somehow, they must find a practical solution that allows them to retain the on-premise infrastructure they have already heavily invested in while taking advantage of new cloud platforms.

The importance of security and access control is amplified when using SSO, a single interface through which an attacker might target multiple applications inside an organization. Likewise, the growing number of cyberattacks targeting IdP providers serves as a reminder that security can’t be taken for granted with any third party.

Threat actors can also target Adobe Sign directly, abusing the Adobe Sign service to distribute phishing emails. The attackers know that this document system is now common enough that unwary employees might open an attachment that appears to come from a legitimate account on the same platform.

Peter Parker’s Uncle Ben said it best: “With great power comes great responsibility.” And balancing power and responsibility is even more important in the context of SSO.

If you work in one of the few cloud-only organizations, you’ll find it’s relatively straightforward to access Acrobat Sign via SSO. Your cloud IdP’s native tools and directory service will do the integration and heavy lifting (usually).

For everyone else — organizations that make heavy use of on-premise applications — using SSO with an IdP will require extensive mapping and workarounds.

Thankfully, there’s another, less complex option in the form of UserLock, an identity and access management system designed to make implementing SSO easy for organizations invested in on-premise applications. Essentially, UserLock can act as an interface between the on-premise world and that of SSO and the cloud. This has multiple advantages over simply opting to use a third-party IdP.

First, your organization can keep using the on-premise Microsoft AD directory you already have. This saves huge amounts of time and reduces complexity compared to integrating via a third-party IdP platform. Administrators can continue provisioning user access using the accounts, services, roles, group policies, and passwords that already exist. What's more, UserLock will enable you to apply true SSO by using your Windows user credentials for SaaS access.

In other words, UserLock SSO knits the on-premise and cloud service realms together from a single console while letting administrators specify a range of security and access controls.

This integration also reduces the likelihood of work applications being used with a personal account. Admins can integrate new cloud applications using SAML 2.0, without implementation bottlenecks or delays.

What’s more, UserLock integrates multiple security controls under one interface. This is important in an SSO context where access involves multiple connection types at once, for example, VPN, RDP, and virtual machines, VMWare and Windows login.

For Acrobat Sign, the user visits the Adobe Sign or Adobe ID login page for that service, which invisibly redirects back to UserLock SSO. This authenticates the user via their existing AD credentials, including prompting for MFA if required. As far as the user is concerned, it’s just the standard login process they’ve completed many times before.

Prerequisites: a domain must first be set up for the Acrobat Sign service. More details of this can be found on Adobe’s support site.

1. Open the Acrobat Sign console, click on Account entry, and expand Account settings in the left pane.

2. Select SAML settings, choosing a desired host name before adding the UserLock entity ID/Issuer URL, https://sso.contoso.com.

3. Then add https://sso.contoso.com/saml/sso in Login URL/SSO Endpoint

4. And https://sso.contoso.com/saml/slo in Login URL/SLO Endpoint

5. Get the UserLock SSO Certificate from Quick Access in UserLock Console. Open it in a text editor. Copy all contents into the IdP Certificate field.

6. Download the AcrobatSign certificate

See Adobe’s detailed instructions for federated SAML authentication.

1. After navigating to Single Sign-On > Configuration in the UserLock console, select Add configuration, then Adobe Sign as the provider to be configured.

2. Next, specify the chosen host name entered into the Acrobat Sign console from the service’s SAML settings page (see 2 above) in the format ‘contoso.eu1.echosign.com’.

3. Enter the issuer as ‘http://echosign.com’, plus the email domain the Acrobat Sign service will use to connect users. Add the downloaded Acrobat Sign certificate (see 6 above).

4. Save the profile and restart the service to initiate SSO.

5. Download the UserLock SSO Certificate from the Quick Access on the right panel. Open it in a text editor. Copy all contents in the IdP Certificate field.

Read more in UserLock’s Acrobat Sign configuration guide.