Since a few days, the "envelope shared" method is deprecated in favor of the new "shared access" mode in docusign.
I try to integrate this new mode in my application, but I can't find the way to access to the envelope shared in this mode.
My use case
An admin user "B" create a shared access from him to the user "A". The user "A" is not an admin user.
When I call the API with user "A" and call the resource "shared access", I can't see any informations about the sharing of the user "B" to me (the user "A").
how the docusign website works to display me the informations
what I found:
the website call a resource:
https://appdemo.docusign.com/api/accounts/xxxx703a26-133a-402b-b770-3ef7e4xxxx/users/xxxx5b82-0ca8-4678-8250-e2364exxx/authorizations/agent?permissions=Send,Manage&active_only=false&start_position=0&count=40
that display the fact that I can manage the user "B". After that the website display the user "B" account/envelope by using the header X-DocuSign-Act-On-Behalf and fill the userId of the user "B"
When a try to use the same entry point from Postman and a valid oauth token I have this message:
{
"errorCode": "API_RESTRICTED",
"message": "The API function is restricted and not available for general use."
}
Otherwise, the usage of "X-DocuSign-Act-On-Behalf" seems to work.
Questions
How I can access to the account user I can manage if I'm not an admin
user ?
Where is the good way to list shared envelopes in the new
mode (what I try to do seems to be a hack)?
Regards,
This is a new feature that is currently not open for developers to use. This may be done in the future, but for now you cannot use this capability in your integration.
Related
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
Hoping someone can shed some light on the following matter;
I got an Angular & .Net core Web API application that uses Azure B2C to authenticate users.
User accounts are created by the users themselves via the signin/signup custom policy or administrator can create accounts via the app using the Graph API.
Due to the requirements, the app uses usernames (as opposed to email addresses) to log into the application. So far I've managed to get everything working except for the following scenario:
When an account is created via the Graph API, the owner of that account cannot reset the account's password. The error is "An account could not be found for the provided user ID".
This isn't the case for accounts that get created via the custom signup policy so I did some comparison and found that for those account that get created via the Graph API, the Email is missing (which can be found under User -> Authentication Methods). I looked at populating that field, but it appears the "Mail" attribute is 'read only' (not sure if that's the right attribute anyway).
At the moment I'm having to manually set the email via Azure so those account's passwords can be reset by their owner if necessary. This is obviously not ideal and wanted to see if there is anyone that might have gotten around this issue, or a least get confirmation that this is indeed a limitation of the Graph API.
Thanks in advance for your help
So I managed to get this working using the approach outlined by Jas Suri. These are the steps that I went through
Created a custom attribute in my B2C tenant to hold the account email address
Included the custom attribute claim type (extension_emailAddress) as well as the strongAuthenticationEmailAddress in the TrustFrameworkBase.xml
Updated my apps's custom policies to include the technical profile for local account discovery. I basically just copied the necessary bits and pieces from here
Updated the local account discovery to perform the comparison against the extenstion_emailAddres instead of strongAuthenticationEmailAddress.
Added an extra step to the Sign up user journey so that the value in strongAuthenticationEmailAddress is copied to extension_emailAddress
Updated my Web API / Graph API "create user" function so that it sets the extension_appidguid_emailAddress
That's it. Now it doesn't matter how the account gets created, the email address will be stored in the extension attribute and the password reset will be able to find the account using that attribute.
happy to provide more details if anyone comes across this.
The problem is as you’ve identified, the Sign Up policy uses the strongAuthEmail attribute to store the verified email for a username based account. The Password reset policy will use this to verify the user owns the username. When creating the user with graph api, you can’t populate this field, it’s not exposed. The only option is to use a custom policy which stores this secure email in an extension attribute, and your graph api created users can then also target the same attribute to allow the stars to align.
Mail attribute is not the same as the Email under Authentication Methods, and currently there is no such graph api to set the Email value under Authentication Methods.
By the way, there is no need to create Azure AD B2C user for a user as users can sign up themselves.
I have 2 questions:
As per the client requirement, while Sign Up using Azure B2C UI flow (signInNames – Type is userName), user should get suggestions for username once they entered some value in username field(on the basis of existing usernames in B2C AD).
How we can achieve this functionality?
Note: I am using B2C built in Sign Up policy.
Other requirement is that multiple user can have same Email Id (as we are already using signInNames – Type : userName ).
So once user enters the email Id and if that email Id is already associated with other username(s), we need to populate the list of usernames associated with the email. How we can achieve this functionality?
Any help is very much appreciated, I actually got stuck so please offer any suggestion.
You mean the "email address" property, right, not the actual email messages? If so, you should be able to use the /users endpoint: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_get
What is the resource you want to access via the access token ? If resource is https://graph.windows.net/,you could use Azure AD Graph API to get the email information of the signed-in user :
GET https://graph.windows.net/me?api-version=1.6
Authorization: Bearer yourAccessToken
If resource is https://graph.microsoft.com/,you could use Microsoft Graph API to get the email information of the signed-in user:
Get https://graph.microsoft.com/v1.0/me
Authorization: Bearer yourAccessToken
In response you could check UserPrincipalName claim value which is an email address that can receive emails.
For the username suggestion part, if you are talking about when you fill out the username form field and the chrome/IE box pops up above, that is cached at the client and you can't do that. If you are talking about the user tries to register with a username that is already taken and you want to give them suggestions you may, but I doubt it, be able to do it in a custom policy. More than likely, however, you would need to use a custom web application to do that as that is more of an advanced sign in journey.
The second part of your requirements would also need to be fulfilled within a custom web application as well, you can retrieve and access AD items within the custom user journey's but again this is more of an advanced sign in journey.
I am using username for the identity provider for local account.
When an user forget their username, is there a out-of-box policy that handle the username recovery? Or I have to implement it my own?
If I implement my own, as sign-in policy doesn't have UI customization that I will not be able to add a link for "For get your username" to redirect the user to my code to retrieve their username. Is there a way adding links on the Sign-In page?
There is no out of the box policy for forgotten username. It seems a nice feature though. But I anyway enforce usage of e-mail as username. And frankly, the way to implement this is a bit of a tricky.
You can first get (and confirm) users e-mail address which is registered with the AAD B2C. You have to send him/her an e-mail with a code to make sure that he/she owns the e-mail. Once you get e-mail confirmation, you can query the Graph API for the list of users and search for the provided e-mail.
As for providing link - you can have fully customized "Sign-in or sign-up" policy, where you can put the link. You need to use the special sign-in or sign-up policy, because currently it is the only one that allows for full user experience customisation.
We are allowing users who have created their accounts with DocuSign directly to connect to an integration we are providing. As a result, we have no control over the account settings in place for each account created.
We are using the SOAP API and our header is comprised as the following.
r.Headers.Add("X-DocuSign-Authentication",
string.Format("<DocuSignCredentials><Username>{0}</Username><Password>{1}</Password>" +
"<IntegratorKey>{2}</IntegratorKey></DocuSignCredentials>",
Email, Password, IntegratorKey));
On envelope creation everything works, however, on the following calls; RequestRecipientToken, RequestUrlSenderToken, and GetAuthenticationToken we are receiving the following error message, "This User lacks sufficient permissions. Fail to resolve SendOnBehalfOf user".
Do accounts created with DocuSign have the API rights enabled automatically? If not, how do you suggest we instruct them to enable them?
Is there a programmatic change we can make to avoid the issue?
It sounds like the BehalfOfUser may be lacking the proper permissions.
The DocuSign user associated with the element in your request must have the following permissions activated/checked in their DocuSign permission profile. As an DocuSign administrator select Preferences > Users. Find the send on behalf of user. Open their profile and check the permissions associated to them.
1) Within the Sending and Signing section, check 'Send Envelopes'
2) Witin the DocuSign API section, check 'Sequential Signing (API)'
Our implementation was correct but we were passing the wrong variables for that particular user. The header listed in the question can be followed for future implementations.