Skip to main content
T
Tom232820513f3u
Participant
July 28, 2022
Question

API Group Security Risk

  • July 28, 2022
  • 1 reply
  • 1245 views

Hello,

I am a Group Admin, within Adobe Acrobat Sign, for 2 groups. The first group ("Restricted Group") is for sending sensitive data requiring additional security. The Second Group ("Private Group") is for sending non-sensitive data internally, only requiring a password on the document sent to email addresses within our company. The security issue occurs when I submit an agreement with the group id of the group with more security requirements ("Restricted Group") using the Acrobat Sign REST API (Version 6) but is using the security requirements of my default (“Primary”) group which was set to the second group ("Private Group"). The reverse is also true when update my profile to default at the first group ("Restricted Group") and need to submit an agreement via second group ("Private Group") causing API to return a bad request security error.

 

Error Message when Submitting an Agreement as a group with less restrictions when your default (“Primary”) group is set to another more restricted group despite being a member of both.

  • StatusCode: "BadRequest"
  • Message: "Request failed with status code BadRequest"
  • ErrorStatusCode:
    • code: "MISSING_REQUIRED_PARAM"
    • message: "Your default signer authentication method is set to Password Valid Password info/security option is missing for member with email: email@emailaddress.org and order:

 

Within the “Acrobat Sign REST API Version 6 Methods” documentation is stating the following for submitting an AgreementInfo model to create a new agreement:
https://secure.na1.adobesign.com/public/docs/restapi/v6#!/agreements/createAgreement

“AgreementInfo { … groupId (string, optional): The unique identifier of the group to which the agreement belongs to. If not provided during agreement creation, primary group of the creator will be used”

 

After submitting a new Agreement, the agreement will display with the appropriate group name in the “Manage” page within the Adobe Acrobat Sign site even though it is not using the appropriate security group when submitting.  I find this to be a is concerning and potential security hole. Is there a way to make sure you are using the selected correct group’s security when submitting an agreement via the API other than logging in and changing a user’s default (“Primary”) group?

This topic has been closed for replies.

1 reply

Meenakshi Negi
Community Manager
Meenakshi NegiCommunity Manager
Community Manager
August 1, 2022

Hi Tom,

 

Thank you for reaching out.

 

We have checked that you are using the Acrobat Sign Enterprise plan. 

As you have a question related to API, the experts can best answer it. I suggest you please get in touch with our Adobe Sign Enterprise support team to get the correct information about this. You may contact them using the steps indicated in the following help document: https://helpx.adobe.com/sign/using/adobesign-support-resources.html.

 

Thnaks.

Meenakshi

    T
    Tom232820513f3uAuthor
    Participant
    August 4, 2022

    Thank you for your reply. The Adobe Sign Admin for VUMC and I have a meeting scheduled. I started on the community help form to see if there was a simple explanation and/or solution that I may have missed in other documents. We were sent the following link prior to our upcoming meeting that I would like to add to this post if anyone is coming here for similar questions: https://helpx.adobe.com/in/sign/using/users-in-multiple-groups.html 

     

    Just on reading online document is seems that I was submitting things correctly by adding “groupId” parameter when creating an agreement from the Adobe Sign REST API (v6) when “UMG” (Users in Multiple Groups) is enabled on the server. Also, the Adobe Sign API v6 seems to be the first to handle “UMG” otherwise it will default to the using the user’s “Primary” group setting when submitting the agreement. See the following quote on setting the “groupId”:

     

    API differences

    “Note: Only v6 of the REST API will be updated to accommodate UMG.”

     

    “v6 REST API endpoints that are executed in the context of a specific group have been expanded to include an optional groupId identifier that can be passed into a request as a query parameter, header, or as part of the request body.”

     

    “This parameter is optional, and if omitted the code defaults to the user's primary group.”


    - Adobe Help: Assign users to multiple groups, https://helpx.adobe.com/in/sign/using/users-in-multiple-groups.html#API 

     

    After further reading, one area of Adobe Sign we will need clarification on is “Integrations”. If one or more Integrations are configured, the “groupId” submitted still assigned to the correct group but use the primary group settings. As indicated in the following:

     

    Integrations

    “All enterprise-level accounts can enable UMG, even when one (or more) integrations are configured.”

     

    “The current Acrobat Sign integration packages do not account for UMG in any way. As a result, all users sending agreements through an integration are perceived to be in their primary group only, and sending parameters will align with the primary group settings accordingly. “


    - Adobe Help: Assign users to multiple groups, https://helpx.adobe.com/in/sign/using/users-in-multiple-groups.html#Integrations 

     

    This fits with what I am experiencing after testing. I can send agreements on behalf of a user as any group that the user is assigned too. However, the setting (like security) of the user’s primary group are still enforced. I think this is something we (VUMC Adobe Admin and I) need further clarification on. The biggest issue with this possible “feature” is if a user’s primary group was set as the lower security group, the API can still create / send agreements assigned to the higher security group. I would expect submission to error out if security methods used don’t match that of the group set in the Agreement’s “groupId” parameter.

     

    I look forward to sharing a positive solution soon.

     

    Thanks,

    Tom

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices