Me and my team are facing an identity and management project where DocuSign should be integrated with IdentityIQ to manager its user accounts and permissions.
As you all know, DocuSign works as follows:
An organization
One or more accounts that belong to the organization
Users that belongs to organization
Our client needs users being able to request account permissions, but also organization admin role.
We are using the API to integrate DocuSign with IdentityIQ and handle its requirements, but we do not know, because it is not in the documentation, how Organization permissions can be assigned to users through API. Do you have any experience on this?
Thank you in advance,
Regards
At this time, Organization Admin functionality is not exposed in the DocuSign API.
Related
I have two accounts for DocuSign, one for demo, and one for production. While implementing JWT Grant oAuth2 workflow, I created a DocuSign Admin (Organization), through demo account . Now, how can I link production account to the existing organization to enable oAuth for production account?
The developer (demo) environment is separate from the production environments.
You should connect your production account to a production DocuSign Organization. If you don't see the organization options, talk with your DocuSign sales person to have the option enabled.
After you have your production organization setup, you can claim the same DNS domain(s) that you claimed with your demo organization.
Because the demo organization is separate from the production organization, both can claim the same DNS domain.
I am running a POC for a Service-based DocuSign integration with JWT Authentication. We would like to leverage embedded sending, enabling multiple customers to send documents for signatures. I am trying to understand how we will manage users and consent in this scenario.
To grant consent for multiple clients, do we need to have a user created in or organization for each of our customers? Do these users need to be admins? Are we able to grant consent to a DocuSign user outside our organization?
Thank you
So, JWT requires consent of the user, but only once. This process is the same as Auth Code Grant, requires the user has a membership in a DocuSign account, log in (not in an iframe) by either entering their password or using IDP for SSO and then they are asked to allow the integration to access specific resources (eSignature in your case) as well as allow it to impersonate them. That is critical for JWT.
If you want to make it a bit easier, you'll have to become an ISV. As an ISV there are ways to consent to an app for an organization and you can also have some level of control over your customers' accounts.
Partner Integration Guide for ISVs
We are working on an integration to offer embedded document signing through customer websites we host. We want this to be a comprehensive solution, so envelopes should count against our quota, but will need to be under the user account provisioned through Docusign. We are using the JWT authentication method to impersonate the provisioned accounts and want to make sure we understand any requirements to gain consent.
When we request and provision accounts for our customers, is our integration key automatically granted consent on that account? Will we need to set up a service user account that can be impersonated on each customer account and grant consent individually? Thank you for any help you are able to provide.
If you (as an ISV) intend to purchase and provide the envelopes on behalf of your clients, you will need to be under an ISV License agreement with DocuSign. Architecturally, you would not be adding your clients are users in the accounts owned and managed by you. You would instead use a "system user" to represent each client organization. This works especially well for embedded signing integrations. As for consent, it would be a one-time consent that your configuration team would accomplish when onboarding the new client.
At this time we don't have these capabilities for ISVs.
Consent has to be given in the organization/account level (admin consent).
Which means if your customers are not in your organization, each of them would have to consent once.
Using administrator consent, your customers would only have to go through this process 1 time for your application.
Please free to send a feature request to partners#docusign.com or contact your partner account manager (make sure you're a DocuSign Partner).
a company provides an app to multiple customers with multiple users. Now the provider wants to let the users use their Microsoft Azure Active Directory to let their users login with their Microsoft credentials.
Is integrating the client with ADAL the right way?
What does the provider and what do the customers have to do to make this possible? The provider registers his app and then the customers grant this app permission? Or do the customers register the app and give the provider some keys?
Thank you very much for any help. Microsoft has so much documentation, but it is so difficult to get the information I want.
The provider should register the app.
Note you must register the app as multi-tenanted.
When another organisation tries to login, they'll be presented with a consent screen, where they must accept the permissions your app requires.
Then in your app, you can further check if this organisation has access to a subscription etc.
Check the multi-tenant guidance for more details: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant
I'm quite new to all things MS/AD and coming from the app developer side of things so please bear with me if i'm not using the right terminology. I can't find confirmation in the online docs for this, so grateful for any ideas or links that could be helpful.
The scenario: my organization is a O365 shop and have a bunch of stuff in Azure. One project is a custom platform with several web apps. Most are accessed by our own folks via SSO, but some of these apps will be accessed by external users from our partners/vendors. A couple of these are MS shops but most are not and we can't require MS accounts.
The twist: we need to delegate user management to our partners/vendors. So as an example, for app3 we will have tons of partner/vendor organizations that need access. We want to give 1 person from that organization the responsibility of inviting their colleagues and removing folks when anyone leaves their organization. In many cases, they won't necessarily have the same email address domains so we can't restrict/group in that manner. In other cases, we need each national office of a global organization to have its own delegated admin to manage staff so there may be separate organizations with users that have the same email address domain.
My questions: Is Azure AD B2C the right approach for this?
Can it support this kind of delegated management (something like https://learn.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-self-service-group-management)?
Would we need configure a separate Azure AD B2C directories for each external organization or should these be groups within one Azure AD B2C directory?
At this time there is no out-of-the-box support for user management delegation in Azure AD B2C, whether it's delegatin user management to other B2C admins using local (.onmicrosoft.com) accounts or external users using local (#myemail.com) or social accounts. Azure AD B2C does not support self-service group management capabilities either. You can request either of these in the Azure AD B2C feedback forum.
Is the same instance of these apps going to support people from these multiple organizations?
If the answer is no, meaning that your are going to have one instance of the app for organization A, and another for organization B, you can definitely have multiple Azure AD B2C directories and wire up each application to each directory.
If a single instance of these apps will need to support multiple of these organization, then I can think of two options for you:
Use Azure AD B2C and build all the delegation and user management logic yourself. You can have a custom attributes to assign users their "organization" and another to indicate whether they can manage users or not. You would then need to create a user management UI that queries the Graph for all users that are in the same "organization" and let the user manage those. You would also need to build the invitation feature, first into this UI by creating the user through Azure AD Graph and setting its "organization" claim accordingly, and then by directing users to the Password Reset policy as their "account verification" flow.
Use Azure AD and the B2B collaboration feature (including its ability to delegate invitations). This also opens up the self-service group management capabilities you referenced. If you don't want these users to get access to other things in your organization, you would probably want to create a separate Azure AD tenant for this and also invite people from your on Azure AD via B2B collaboration.
Conceptually, B2C is meant for external users, and Azure AD is meant for internal users, with B2B complementing those internal users with partners that collaborate enough with those internal users to be almost thought of as internal users. That being said, use whichever one best suits your needs. Don't forget to keep in mind that their pricing model is very different.