I have a WPF application that uses the Microsoft.Identity.Client package to authenticate users using Azure AD B2C. This works well on Development, but when I distribute my application with the Setup Project, my application is installed on the Program Files directory, which is a read-only directory. I assume that MSAL writes tokens or cache files to the directory the exe is running; so, when the application is initialized without admin privileges, the app cannot write to the directory, and therefore cannot authenticate users.
I've initialized an instance of IPublicClientApplication within the OnLaunched method like this:
PublicClientApp = PublicClientApplicationBuilder.Create(ClientId)
.WithB2CAuthority(AuthoritySignUpSignIn)
.WithRedirectUri(RedirectUri)
.Build();
TokenCacheHelper.Bind(PublicClientApp.UserTokenCache);
Related
can I login a user to AAD without using an App Registration?
My problem is the following:
I am currently writing a python module that wraps the Power BI REST API.
Everything works fine if I register an app in AAD and authenticate via Client ID and Client Secret.
I would like to enable a user login, so that a user logs in with their credentials and can run the script with the privileges assigned to their account.
MSAL seems to support that with a PublicClientApplication and the acquire_token_interactive method. It still expects a Client ID, though.
My issue is that I would like to distribute my python module to other developers, without them having to register an app in AAD first.
After all, I can use the MicrosoftPowerBiMgmt PowerShell module without first registering an app.
How can I do that? Is there an authentication flow that does not need an App Registration?
It is not possible to authenticate user without App registration with OAUTH and OPENID connect, multi-tenant authentication means a template which will be deployed on multiple tenants with same client-id and secret
I have a website hosted as Azure App Service with Azure Active Directory authentication enabled. Users can sign in from their browser using the interactive workflow.
The website must run as a dashboard on a big screen 24/7. There it is not possible to use the interactive workflow for authentication there, since there is no user to enter credentials.
How can I achieve this?
Is it possible to use a service principle with a client certificate? If so: How?
You can use the client credential flow to obtain a token to call the Web API hosted in your App Service on your behalf (not on behalf of the user). This solution is useful for non-interactive daemon applications that perform tasks without logged in users.
Since you have enabled Azure AD authentication in the app service, you only need to register the daemon app in the Azure portal. When you use the client credential flow to request the application hosted by the APP service, Just replace resource with the application ID URL hosted by APP service.
please see:here.
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.
Is it possible to execute Windows PowerShell command to register an application to ADFS using ClickOnce deployment?
I am working on a WPF rich client application. The application using REST API to authenticate and get data. The authentication will be performed by Active Directory Federation Services. As to authenticated and to get token, I have to register the client application with ADFS, can I execute PowerShell command through clickOnce setup to register application to ADFS?
You can register the client in ADFS using powershell, but that is something that is done only once in the ADFS server itself. So I don't see the benefit of including that registration through clickOnce. This document describes your scenario (WPF client + OAuth + ADFS), you can find more information there: Developing Modern Applications using OAuth and Active Directory Federation Services
I am trying to call graph api URL https://graph.microsoft.com/v1.0/me from a native application but get access denied.
If I call web api authorized controller from the native app, I successfully authenticate.
When I try to make a REST call in the backend, I also get access denied (providing user's token).
I have tried to implement it via HttpClient class (for the native app), and adal.js for the front-end - in both cases I successfully authenticate against the web api controllers decorated with Authorized attribute, but cannot call Graph API service.
I have run a web debugging proxy and ensured that the authorization header is sent properly.
I have done the following:
Created Azure Native App
Created Azure Web App
Provided permissions of the native app to the web api app
a. Added Read Directory Data permissions to the default permissions
Entered redirect URI in the Native app - same URL as the one of the Web API
Updated the Web app manifest from Azure AD. Set oauth2AllowImplicitFlow to true
Provided permissions of the web app
Windows Azure Active Directory:
a. Application Permissions - Read Directory Data
b. Delegated Permissions: Access directory as signed-in user
c. Delegated Permissions: Read Directory Data
d. Delegated Permissions: Sign in and read user profile
Microsoft Graph:
a. Delegated Permissions: Sign users in
b. Delegated Permissions: Access Directory as signed in user
c. Delegated Permissions: Read Directory Data
d. Delegated Permissions: Read all users' full profiles
e. Delegated Permissions: Sign in and read user profile
f. Application Permissions: Read directory data
g. Application Permissions: Read all users' full profiles
Consented the native app successfully
Consented the web api app successfully