Configuring Adobe Acrobat Sign for Government

Welcome to Adobe Acrobat Sign for Government

The Acrobat Sign environment for government use is engineered to be FedRAMP Moderate compliant and has significant changes from the commercially available environments. For this reason, it is strongly recommended that administrators setting up a new account in this environment read the below overview, even if you are familiar with previous Acrobat Sign trials or production accounts.

To provide for a FedRAMP Moderate compliant authentication portal, Adobe has partnered with Okta, a leader in the Identity as a Service space. Okta is used as the user management system, gating access to Acrobat Sign. All users must be provisioned in Okta before their userID can be provisioned in Acrobat Sign. Customers can elect to use Okta as their stand-alone authentication service or configure their existing directory service/SAML 2.0. compliant identity provider to manage user identity.

Once Adobe provisions the account, the first administrator receives an email from Okta that includes a one-use activation link to the account's Okta portal and the domain-claiming token needed to provision users on the Acrobat Sign system.

It is recommended that upon receiving this email, the following six steps be taken as soon as possible:

1. Use the one-time activation link to log in to the Okta system and set your password. The link expires in seven days, and if the password isn't set in that time, the account will need to be reprovisioned.
   • Bookmark the Okta portal when you authenticate. Your Okta portal URL is unique for your account, not a general access portal that you can discover in public documentation.
2. Contact your network administrators and start the process of claiming your domains. The environment is designed to prevent creating users with email addresses in domains that are not explicitly claimed by the account. The domain claiming process can take longer than you might expect, so starting early is recommended.
3. Create a second administrator in the Okta system manually. Don't risk having something happen to the first admin that locks the system in a way that requires the account to be reprovisioned. Don't invest a lot of time in making users manually. They can't be provisioned in Acrobat Sign until the domains are fully claimed, and you are better served by hooking your directory or identity system into the Okta system (step 5 below).
   
4. Review the system requirements, particularly the network configurations. If you have significant network security, you should get your network administrators in the loop as soon as possible to ensure that you can properly connect and function in the Acrobat Sign environment.
5. Connect your directory or SAML 2.0 compliant identity provider to the Okta user management system.
6. Start configuring the account level of the Acrobat Sign system. Keep in mind that property inheritance passes from Account to Group to Users/Agreements. Configuring the account level seeds those values into all subsequently created groups. Consider the two most common philosophies when defining the account-level settings:
   • Configure the most common use case, minimizing the amount of group-level configuration required.
   • Configure for the most stringent security requirements, safeguarding against missed setting options, and force an explicit weakening of the safeguards at the group level.

Also worth considering is defining default values where you can and reducing the number of options for users to select from. This will reduce questions about features you don't intend to use and streamline training.