In Azure logic apps I want to create a workflow which creates a user task and till user has taken action the flow will be in hold - azure-logic-apps

In the Azure logic app we can send an approval email. In the email we can take action. Until the action is taken by the user, the workflow will not move to the next block. But I want the same thing to be done through a Rest API. Want to take action and approve or reject through a rest API in Azure Logic Apps?
This is the workflow:

Related

Single sign on as alternative - Azure AD B2C

We have a website that has its own register/login logic. The user table, passwords...
As a business requirement, we need to integrate a 3rd party website, seamlessly to our users. So when a logged-in user clicks on the 3rd party's link he should be logged in straight away and has passed user details.
The 3rd party website supports single sign-on, and ideally, we would like to use Azure AD B2C to implement SSO.
Is it possible to keep Azure AD as an alternative place of login? So we still register a user via our website, use our login, but when a user comes to the other website he logins via Azure AD. Basically, this would imply pinging Azure AD via Rest API whenever we have a new user and passing his details there, but also somehow asking Azure AD to do the login verification with us using a REST API on our side
Is this achievable, or there is a better way of implementing this?
Thanks
There is a way you can follow I have design it as well in the below picture. From this way it can be achievable
Step 1: Store the new user in data base that is signup in website1.
Step 2: Export the user list in CSV format.
Step 3: Upload the CSV file to storage account and the WebJob will be reading it to create users into the B2C directory.
Step 4 : if any new user comes for login in 3rd party website it will redirect to website 1 for register and if existing user comes it will prompt for Azure ad B2C authentication.
Please follow this document to implement the above scenario:
https://blog.kloud.com.au/2018/10/30/bulk-import-users-into-azure-ad-b2c-tenant-with-custom-attributes/

Azure AD OBO Reconsent

I'm currently developing an application which consists of a frontend SPA which makes request to a Node backend. The Node backend makes requests to MS Graph. For this usecase I set up the OBO flow which works fine.
The SPA uses MSAL.js to request a token for middle tier API with /.default scope. The middle tier API knows the client as 'knownclient' in its Manifest. On very first login the application wants the user to consent to the combined scopes from client and middle tier. (If the user never used the app before)
The problem now is the following: By going further in the development process, new scopes are added for MS Graph in the middle tier API. However the client doesn't show the consent prompt to the user for giving his consent to use the new backend scope although using the /.default scope in the client.
The first approach I had was settings prompt='consent' to the MSAL setting in the frontend. This approach works but results in asking the user for consent every time he logs in.
The intended behaviour would be to just ask for consent if the middle tier API changes its scopes.
How do I have to set up my applications to get this result?
As I said in the comments, if you just add new permissions, don't use prompt='consent', because this will cause the administrator consent page to be triggered every time you log in as a user.
When you add a new permission, you only need to grant the administrator's consent, and there is no need to request the user's consent again. So, you only need to grant the administrator consent in the Azure portal. Or, use the url that the administrator consent to: https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}.

Using IdentityServer to call API on behalf of a Client not User?

I am thinking of using IdentityServer4 for a new project. I am new to this and have done some reading and seen some of the demo clients in action.
Most of the clients in the samples allow login as a User and issue a token.
Requirement
I have multiple applications and the are for example, MVC/SPA/Mobile etc. I wish to allow each application to be a client and call an API.
I need a setup where applications can call a protected API without a user being logged in. So the API is protected based on scopes.
I know I can use client_credentials flow to get access_token and call my API. Which is fine for apps like the MVC as the secret will never be exposed.
I read that this flow is not recommended for mobile/SPA apps and to use Authorization Code flow, but I can't seem to get a token without it asking to login as a User.
Question
What other flow can I use to get only access_token without logging in the user and keeping my app secure?
Or, should I just use client_credential flow in my mobile apps and SPA's?

Azure AD B2C send invitation email to new user

Using the new Azure AD B2C service in preview, I am looking to be able to send a user an invitation email to complete sign-up for our SaaS application. Each of our customers will manage their own users and I want them to be able generate an invitation email to their new users for access to our SaaS application. That user would then finish the sign-up process.
Part of this process will also to be able to include what "customer" this user is assigned to. Part of the invitation process I would like to be able to identify that this customer should be a part of this customer's database in our SaaS application.
This is not a supported feature. I recommend that you use our User Voice forum to make feature requests; we are tracking those.
There is an existing feature request for this: AADB2C: Send email invitation for new user to sign up
You can use custom policies to achieve this. You can send a JWT to B2C that includes the 'customer' the user is assigned to.
There is sample code here that sends the JWT to B2C.
The leaf policy that receives the JWT is here.
The sample app is here.

Connect a salesforce user to another salesforce user in another org without any user intervention

We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.

Resources