- Welcome to Adobe Acrobat Sign for Government
- First steps for new accounts
- Claiming an email domains
- Connecting Okta to a federated identity solution
- Manually create/edit users in Okta
- First steps for new accounts
- Configure Acrobat Sign
- Configuration Overview
- System requirements
- Branding
- User access to features
- User experience within the application
- Recipient experience when interacting with agreements
- Transaction security
- Compliance information
- Configuration Overview
- Administrator processes
- Admin guide overview
- Users
- Groups
- Templates
- Custom workflow designer
- GDPR deletion processes
- Sandbox
- User environment and processes
- Support resources
- Transaction limits
- Page layouts
- Configure your profile
- Send agreements
- Compose an agreement to send for signature
- Recipient signing order
- Written signatures
- Send an agreement to yourself only
- Send in Bulk
- Sending from a template on the Manage page
- Sign agreements
- Fill and Sign a document
- Self Signing
- Signing a document from an email link
- Sign a document from the Manage page
- Compose an agreement to send for signature
- Custom workflow designer
- Manage agreements
- Search for agreements
- View Agreements
- Activity history and Audit Report
- Add a note to an agreement
- Set a reminder
- Cancel a reminder
- Add an expiration date
- Modify/Delete an expiration date
- Modify the files of a sent agreement
- Replace the current recipient
- Upload a signed agreement
- Share an individual agreement
- Download an agreement
- Download the individual files of an agreement
- Download the audit report
- Download the signer identity report
- Download the field data from an agreement
- Cancel an agreement
- Hide an agreement from view
- Reporting
- Create a report with classic reporting
- Report charts and data exports
- Data Exports
- Report Charts
- API
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:
- 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.
- 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.
- 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).
- 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.
- Connect your directory or SAML 2.0 compliant identity provider to the Okta user management system.
- 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.
A word of caution around adding users early.
The process of creating a user in Acrobat Sign is triggered by adding the “Adobe Sign” group to a user in Okta. <Insert URL for instructions>
The first thing the process checks is the domain of the email against the list of claimed domains for the account.
- If the domain isn't listed as claimed in the account, the user isn't created in Acrobat Sign. However, it is active in Okta, with the group assigned, giving the appearance of a created user.
- If the domain is later claimed, the user will not automatically be provisioned because the trigger is the action of adding the group. An admin would have to remove the group and re-add it to each impacted user to start the provisioning process.
Once the email domains are claimed, you can link your directory/IdP to Okta or manually add users as you wish, and the users should be created without issue.