I've created a SPFX feature that needs to call an external API. The external API is part of a system that has its own authentication methods outside of SharePoint. Ideally I would like to send details about the current logged in SharePoint user to this API, validate them to ensure that the user is actually logged in in SharePoint, compare the SharePoint user with the external system's user (they'll have the same email addresses) and, once matched, run the external API's code with that user.
Is there any way to go about doing something like this? If not, what is the best way to handle this sort of problem? Do other Microsoft tools like Azure need to be used for this?
The supported way to authenticate SharePoint framework components to a custom API is by using Azure Active Directory (AAD) and OAuth.
You need to AAD-protect your API. You can configure it so it supports two authentication mechanisms: AAD and your current authentication method. For example, if a JWT token is present, you use AAD+OAuth, and if not you use your other authentication method.
The SPFx to API authentication mechanism is described in details in the page Connect to Azure AD-secured APIs in SharePoint Framework solutions.
In summary, you will need the following elements:
Register an application in Azure AD, which represents your API.
Use a server library to protect your API with that AAD application.
Configure your SPFx package so it has permissions to query your API.
Grant the permissions to your SPFx package in the SharePoint central administration.
Use the AadHttpClient in your web part to access your API.
Related
I have to integrate SharePoint with my web app(just want to show the content of the user account).
For that, I have researched and I am looking for the SharePoint integration with REST API through OAuth process, Right now I found a different way where users have to create their SharePoint app and they have to share username and password and then I can get the data with their credential for the users.
The above approach is not a good option.
Please help if someone knows how to get share point content through the OAuth approach with REST.
You are able to connect to Microsoft Graph which hosts an API for the Office365 entities such as Calendar, Mail, Sharepoint etc.
In order to authenticate, you need to follow the OAuth 2.0 flow. This involves the generation of access tokens, which are then used in case of username/password.
More information about the MS Graph API and setting up authentication as well as a number of SDKs can be found: https://learn.microsoft.com/en-us/graph/auth-register-app-v2?view=graph-rest-1.0
We need our active directory to manage the autentication from the site, is there a way to configure the crafter-delivery profile/security in a way like we can do in studio?
Users added to the internal database after the user’s first successful login through external authentication are marked as **Externally Managed**.
There is no engine-config-override.yaml so i dont know how to do it.
The documentation says something about it, but its not explained anywhere.
Crafter Profile is built on MongoDB for extensibility and extreme
scalability and includes a multi-tenant profile attribute store, an
admin console for user profile management, chained authentication with
any existing authentication services including Active Directory
https://docs.craftercms.org/en/3.1/developers/projects/profile/index.html
Crafter Engine uses Crafter Security Provider library, which can be extended to support LDAP/AD.
Another, perhaps easier/better option is to just use SAML2 and not only will the users authenticate against AD, but they'll also get SSO.
Here is the guide: https://docs.craftercms.org/en/3.0/site-administrators/engine/engine-site-security-guide.html#add-single-sign-on
Is it possible to flow the user credentials from a CRM plug-in to a web API hosted in Azure?
I'm working on a project where a Dynamics CRM plug-in will make a call to a custom ASP.Net Core 2.0 Web API hosted in the same Azure tenant.
I have no Dynamics CRM experience; we have a team member who has done a lot of CRM integration, but he's always used a service account to connect to the other application.
I'm trying to avoid that.
Ideally, this web API would perform some work using the credentials of the CRM user, since the user's credentials will be valid in both CRM and the web API.
I would really like to have the user's credentials (such as email) come from a trusted authority and not just passed by the caller. I already have code that pulls the user's email (for example) from the user's Claims (from another part of the project).
In my perfect scenario, the plug-in code would pass the user's OpenID Connect to the web API; but I've found nothing that indicates that CRM supports OpenID Connect.
I have seen articles that talk about calling CRM from an external application using Oauth, but nothing that shows CRM calling a service with any kind of token-based authentication.
A fallback would be to use an OAuth bearer token, and have the plug-in pass the user's information to the web API.
Does anyone have any information on how to flow the CRM user's credentials to a web API call, or acquiring a bearer token to pass to a web API?
Thanks
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.
I want to store user information to a db after a user successfully logged in via a social provider (google, facebook, etc.) without calling an extra api on the client side.
In azure mobile services this is done by creating a class that inherity from e.g. GoogleLoginProvider and then by overwriting the CreateCredentials method.
See this post: Save information immediately after Google login in Azure Mobile Services (.NET Back-end)
But how can I archive the same behaviour in Azure App Services?
Thanks
Unfortunately this is not possible with App Service authentication. The authentication happens outside of your application and there aren't currently any direct hooks into the authentication pipeline. This also means you will not be able to inject custom claims into the ClaimsIdentity.
We are aware of some of these scenarios and want to try and address them, but don't have any timelines to share at this point. I believe the separate API call into the backend will be required in order for you to implement your registration. As far as implementing role-based access control, you will likely need to store the additional user metadata elsewhere.