Background
I create an CSP Customer (Azure Active Directory) through the REST API and then connect this customer to my Azure Stack. In order to automatically connect their account with the Azure Stack I need to grant this from both sides, customer account and my Stack.
Hence, I need to use the customers password to login and grant Azure Stack access from the customers side.
Problem
I create a CSP customer (password cannot be set during creation) and the password is returned when successful (using the CSP REST API). The password is automatically set to be changed at next login. Hence, I cannot use the returned password programatically until manually setting a new password (not wanted!).
Is there a way to change the customer password using the REST API? Either through CSP or Graph API?
It was possible to change the password for the newly created CSP customer by using the CSP REST API. However, it must be accessed with both API + User credentials in order to be able to change the password.
Change password REST API request:
https://learn.microsoft.com/en-us/partner-center/develop/reset-user-password-for-a-customer
Credentials as described in Partner Center authentication. This
scenario supports authentication with App+User credentials only.
Related
Currently our team is struggling with propper architecture of Azure B2C solution for our multi tenant app.
Here is what we want to achieve. We want to enable users from certain Azure AD to authenticate. This is nicely described here with restricting tenants we want to enable.
We just want to enrich this solution with google authentication. We do not want to enable all users to be able to sign up. Is there a possibility to create google federated user programatically? We basically recieve list of emails from customer company and we create accounts in tenant). As far as I know there is no possiblity to achieve this using ms graph API when I don't have issuerUserId of user.
Do we have any possible solutions for this type of scenario? Like invitation email or so? Or maybe B2C is not a propper solution in this case.
Thanks in advance
A solution would be create the allowed users in b2c as a local account in graph api with accountEnabled as false and some generated password. Since the accountEnabled is false, user will not be able to sign in or reset the password as the default set of custom policies verify that attribute.
In the federated flow in custom policy,
Let the user complete federation.
Read the account using email address received.
If a local account exists, then link the federated account (Write alternateSecurityId to the account using objectId).
If a matching local account cannot be found, block the user by showing a selfAsserted page saying you are not allowed to sign up/in to this application.
You could also have some custom boolean extension attribute set to the local account to have an extra validation and update it's value once user completes the signup.
We have done one CRM integration where we as an CRM have our own docusign pro account.
We completed the GoLive process successfully and have all required data like Integration key, Account Id, Client Id and Secret Key for App.
Now this CRM integration will be used as an mediator for our clients who will have their own purchased docusign accounts.
So till now we have 2 accounts,
CRM Integration docusign account with GoLive status.
Client account to send their own documents for eSign through our CRM integration.
What we have achieved till now?
We completed the consent flow where we redirect our clients to docusign consent page where they provide consent to our app by login into their docusign account. In this flow we use CRM integration account id in URL which takes our client for consent page. On confirm the client will be redirected back to CRM with auth code attached in redirect URL.
We use this auth code to get access token for this client. We use CRMs account id, Integration App secret key and clients auth code to get the access token. We are successful in this too. We get clients access token. No Issues.
Now when our client is trying to send a document for eSign using the access token received in step 2 above, the docusign throws an error saying INVALID_USER.
I have referred to this post Simillar Issue it kind of approves of what we are trying to achieve but it is failing with error.
Let me try to explain and make sure it's clear.
The IK (Integration Key) is global for the entire environment. By environment I mean either the developer environment, or the production environment. When you went live and completed the process using a production environment - you made your IK available for any account and any user in the production environment.
Now, when you get an access token to make API calls, this token is for a specific userId. The userId can be a member of one ore more accounts as showed in this diagram:
The userId is provided by the user logging in when given the option to consent. So when you doing your consent flow, there's a web browser and user that logs in, that is the userId that consent.
Separately, when you request a token using JWT grant, you provide a userId, that userId is a GUID for a unique user in the system.
This GUID must be for the same exact production user that gave consent. That's first thing to confirm.
Now, if you already have an access token to make API calls, when you make a specific API call, you need to provide an accountID. That's another GUID representing an account, not a user. The userId that was provided to the JWT Grant flow must represent a user that has a membership (it is a member of) in the account for which you provided a GUID (a user can be a member of more than one account). That is the second thing to check.
Lastly, there's a baseURI that is used to make API calls and it can be different for different accounts. You need to also confirm you are using the correct one.
For context, we are currently developing a DocuSign integration on our DMS web app product. So far what we have done is that the web app's admin (we assume this would be someone like our customer's IT) can set up the integration by entering API Account ID, Integration Key, Secret Key, Access Token & Refresh Token. All these information was taken/generated using a DocuSign admin account. With this, we see that any user using the DMS can send out signing requests (via API) without logging in to their own DocuSign account.
However, we realised this means that all signing requests will be sent using the common DocuSign admin account, i.e. the envelopes originate from the admin account and all signed documents also stored in the DocuSign admin account. This is not what we want as the DocuSign admin can see confidential signed documents.
I'm quite confused and would like to seek advise on how should we go about this? Ideally, it is that User A of the DMS can associate his DocuSign account with his DMS account. So that when User A sends out the signing request from our DMS, the signer receives the email from DocuSign showing it is from that user instead of the common admin account.
Also, it looks like the go-live process would have to take place for each customer that is using our DMS? Does it mean like each customer need to have their DocuSign developer account so that the integration key can get promoted to production environment? Or am I in the wrong direction & should look at Partner Integration as ISV?
If your DMS system is a SAAS system, then you can have 1 integration key (client id) for your integration with DocuSign. In other words, your individual customers would NOT have their own integration keys, secrets, etc.
One integration key is the best, if your application's architecture can support it. To do so, you'll want to have one or just a few Redirect URIs to enable your users (who also have DocuSign accounts) to authenticate with DocuSign.
Your app then stores the resulting access token, refresh token, and expiration date for each of your users who have authenticated with DocuSign.
This way, as you say, when your users send out an envelope for signing, it will belong to their own DocuSign account, and will show them as the sender.
When your customer wants to send via DocuSign, your app checks the expiration date for the person's access token. If the access token has expired, then use the refresh token to get a new access token and a new refresh token.
The refresh token is stored in your app's non-volatile storage (encrypted is best) so you can use it days or weeks later for the user. That way they don't have to re-authenticate with DocuSign. For this case, use scopes signature%20extended
For the account_id info, use the user's default account and enable them to switch to another account if they wish.
More information:
Getting started for ISVs
API integration guidelines
I implemented Authorisation Code Grant like the example code provided using passport and it is working fine.
One thing that is confusing me is that when obtaining a new token, passport required authentication.
Are these supposed to be the credentials of our admin account? or, once we go live, is it the credentials of our user who is trying to sign a document (using embedded signing).
Thanks!
When you say
our user who is trying to sign a document (using embedded signing)
note that signers do not need a DocuSign account. They can have one, but they don't need one.
If you want to use embedded signing for a signer who does not have a DocuSign account, use a system account (and JWT Grant) to obtain the Signing Ceremony URL. (A system account can also be used to create the envelope, if necessary.)
Added
A "system account" is a user account in your DocuSign account that represents a generic, system, sender. For example, create a user account "Sales department." Then use JWT Grant (on your backend web server) to impersonate the Sales department user. The result is an access token that your application can use to create envelopes and then have them signed by your website visitors.
The "Sales department" user will be created and controlled by your system administrator. But there is no need for the system administrator to login every morning -- once the system administrator gives consent for the application to impersonate the Sales department user, your application can create new access tokens as needed that impersonate the Sales Department user.
The latter. When using Auth Code Grant, every user of your application will have to log into DocuSign and their credentials will be used.
Read more over here - https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-code-grant
I am trying to gather metrics info of azure resources. For that i need an access token to authorize. But to get an access token i have to give client id, client secret, subscription id, tenant id.I was wondering if i could get this access token without giving so many details except username and password of my azure account.
Basically you need the parameters. Azure's APIs are protected by Azure AD so you have to authenticate against it first. If you want to make calls as the user, you still need to authenticate with one of the few ways available. The password grant (as shown in #4c74356b41 answer) is one option, though it is not really recommended. The reason is that if the user's password has expired or has MFA enabled, it won't work.
What you usually do is request the user to login via Azure AD sign-in page (via redirect or web view), and then exchange the resulting authorization code for an access token and refresh token. Then you can make calls against the APIs as the user.
Another option is to register your app in Azure AD and grant its service principal some roles in your Azure subscriptions/resource groups/resources. Then it can authenticate with client credentials (using only its client id and secret + your Azure AD tenant id).
it is possible, but it is considered not safe. And you would still need a lot of parameters:
Name Description
grant_type The OAuth 2 grant type: password
resource The app to consume the token, such as Microsoft Graph, Azure AD Graph or your own Restful service
client_id The Client Id of a registered application in Azure AD
username The user account in Azure AD
password The password of the user account
scope optional, such as openid to get Id Token
Reference:
https://blogs.msdn.microsoft.com/wushuai/2016/09/25/resource-owner-password-credentials-grant-in-azure-ad-oauth/
ps. Don't mind Walter, he is wrong like 50% of the time in his answers.
It really depends on your need and if you want this fully automated or not.
If you want to have a token for a ServicePrincipal, the answer of 4c74356b41 is a great way to do it.
However if you would want to obtain a bearer token for a user (you or another AAD user) that is already authenticated in a PowerShell session, you could do this very easily if you use this piece of code that I wrote.
https://gallery.technet.microsoft.com/scriptcenter/Easily-obtain-AccessToken-3ba6e593
Basically what it does, it fetch the current token from the token cache and return it to you. This way you don't have to deal with clientId, cliendSecret or certificate. I use this all the time when I need to call the Azure REST API on a Just In Time fashion.