We are building a WPF application which communicates with a WCF service (hosted in a Windows Service) for data access, business logic, etc.
The application runs on a domain user account, the WCF service on a server account.
This WCF service should send emails, create and modify events, etc by using the domain user account. Communicating with Office 365 will be done by Microsoft Graph API, using MSAL and Microsoft Graph Library.
The domains active directory and Azure Active Directory are connected.
How can I connect the Graphs GraphServiceClient using the WCF's ServiceSecurityContext without login dialog? (Map a domain user on a AAD user).
Are there any samples available?
What you are looking for is a sample for a 'daemon' service. There is documentation here on this.
https://azure.microsoft.com/en-us/resources/samples/active-directory-dotnet-daemon-certificate-credential/
Essentially you'll need to create a certificate and register it with the Azure AD application. Then when calling the Microsoft Graph, use that certificate so that thee service trusts its really your service.
Related
I'm not really sure what to call this but basically I have a service app that just serves up an API while occasional calling external APIs in the background to keep the data updated. Aside from authenticating to the external APIs there is no other authentication on this app.
Then, I have a front end app that uses the API of the service app to get data and display it to the user, and optionally modify some of the data. This app is setup to authenticate against Azure AD and has app roles setup to restrict access to various sections.
How would I secure the service app API so only calls from the front end app are served, and everything else gets rejected with 401?
You can protect the API by using OAuth with Azure AD. The below overview can help you out with your scenario:
Register an application in Azure AD to represent the API. Reference
Basically in this step, you will be making sure only the application (your app) who has permission can access the API.
Register another application in Azure AD to represent a client application.
Reference.
In this step, you are creating another application representing your app so that trust can be created between API and your app.
Grant permission in Azure AD. Reference.
In this step, you are giving permission to your app to access your API.
Make use of Client Credential flow to authenticate your app to your API. Reference.
In this step, you will be configuring your app with the information of Azure AD application of the API. Using that information, you will be retrieving access token and you need to pass this access token to your API.
I have a WebAPI based master web service which provides a list of Azure Service Bus Relay endpoints for on-premises WCF services based on the client who logged onto the Master Service via a WPF desktop App using ADAL Azure Active Directory logon. This works fine, and the master service returns a Service Bus endpoint for the client who logged in.
The client can then connect to the WCF on-premises service via the returned Service Bus endpoint no problem.
However there are certain methods in the on-premises WCF service which need to impersonate the calling client-user and this is where I am stuck. Does anyone know of a way to be able to impersonate a client who has called a WCF service via the Azure Service Bus relay?? I can't "log the user on" in order to impersonate them because I don't know their domain password, I only have available their logon UPN.
You can potentially solve this problem in the same way I did when writing a paper about flowing an identity through azure service bus queues. You would need to have elevated priveledges for your service account running the on premise service which may introduce a vulnerability depending on how your solution works but if you can mitigate that then this approach would work.
The paper is on the following link:
Flowing a Windows Identity through Azure Service Bus Queues
http://microsoftintegration.guru/publications/whitepapers/
Hope this helps
Mike
I was wondering if the Office365 API supports service level accounts yet. By service level, I mean that a single "service user" (an application for example), can authenticate itself over OAuth2 against our O365 account and access all of our users mail, calendars and files on their behalf.
We're aware that you can do this using EWS (which we have been doing), but we really want to get using O365 REST.
Thanks
Not yet, but we're working on it. Follow me on Twitter (#JasonJohMSFT) or watch our blog (http://blogs.msdn.com/b/exchangedev/) for the announcement.
I am trying to create a cross-platform app that allows a user to login to Azure Management Portal using his Live ID and manage his services. I know that the REST API can be used to access the Management portal.
But I am not sure how to implement the authentication part of it. I have gathered that to authenticate, the user has to upload a X.509 certificate for every request (if it is done by REST) or he has give info like subscription id, domain name etc. and also create a new application in the Active Directory of the Management portal using ADAL library.
But the user isn't expected to do this. Is there anyway to access the Management portal using ONLY the Live ID and password the user provides. Another dilemma I have is whether authentication can be implemented in a portable class library. The required classes for X.509 certificate are not accessible in a PCL. So, does authentication need to implemented for every platform separately?
i have a WCF service hosted in a managed windows service. This WCF service communicate with sharepoint through the client object model in order to create, delete and update the document. My WCF service use a netTCPBinding with message security and windows authentication.
I need to retrieve the identity of the caller to have the right user under the property 'create by' of the sharepoint document.
Without activating impersonation, the wcf run under an network application account (app_svc) and when i create a document, the 'create by' property have this value: 'app_svc'
When i use impersonation, the sharepoint give me a http 401 error. The WCF service and sharepoint are not on the same machine.
How i can do it? Note that i have no rights and no access on the Active Directory and the domain controller server.
Any Help would be appreciated.
i am not familiar with sharepoint. but when you're impersonating a client and try to forward the credentials to another machine, you have to ensure the following items:
the client gets authenticated through kerberos (set SPNs)
the sharepoint authenticates users though kerberos as well (set SPNs)
delegation to the target SPNs is activated on the technical domain account of the IIS application pool / service. If it is running under a local built-in account (network service, local system etc) delegation has to be activated on the computer account object in AD.
The whole scenario is also known as double-hopp scenario.
I cannot write a complete guide here. Best you google for impersonation, delegation and double-hop.
All the steps i mentioned require access to a AD domain controller.