I have a system that logs into a native wpf app via an web api on azure.
AuthenticationContext authContext = new AuthenticationContext(string.Format("https://login.windows.net/{0}", authority));
AuthenticationResult tokenAuthResult = authContext.AcquireTokenAsync(resource, clientId, new Uri(redirectUri), new PlatformParameters(PromptBehavior.Auto)).Result;
if (tokenAuthResult == null) return;
Credentials.RestCredentials = new TokenCredentials(tokenAuthResult.AccessToken);
Credentials.UserName = string.Concat(tokenAuthResult.UserInfo.GivenName, " ", tokenAuthResult.UserInfo.FamilyName);
This all works perfect, with returning token etc.
The users are all in ADAL, and have associated groups against them (these are all O365 users).
I want to be able to query what the logged in users associated group(s) are.
Do I need to make a new call out using the Graph api?
Do I use the returned token?
I'm a little lost here.
Thanks in advance
Scott
to add to #juunas's answer, the following sample active-directory-dotnet-webapp-groupclaims explains things in details.
In particular Step 3: Configure your application to receive group claims explains the app configuration in the manifest.
See also the claims related to groups in https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims#claims-in-idtokens
An easy way is to go to your app registration in Azure AD, click on Manifest, and modify the groupMembershipClaims property:
"groupMembershipClaims": "SecurityGroup",
This will result in the Id token containing the user's group ids.
It does have a limit though, only a certain amount of groups can be included, in which case you would have to get them from Graph API instead.
Here is the endpoint you would need to call in that case: https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/functions-and-actions#getMemberGroups.
Related
I am developing a .NET Core Console Application (C#) that needs to authenticate to an Office 365 IMAP account. The purpose is to retrieve mail and process CSV file attachments unattended.
The app has been registered on Azure as a Mobile/Desktop app with the RedirectUri set as http://localhost.
The following code causes a new tab to open in Chrome web browser and asks for the Outlook account to use for login. I need to stop the browser from opening and handle authentication completely from code.
Current Code:
using var client = new ImapClient(new ProtocolLogger("imap.log"));
var options = new PublicClientApplicationOptions
{
ClientId = _options.ClientId,
TenantId = _options.TenantId,
RedirectUri = "http://localhost"
};
var publicClientApplication = PublicClientApplicationBuilder
.CreateWithApplicationOptions(options)
.Build();
var scopes = new[]
{
"email",
"offline_access",
"https://outlook.office.com/IMAP.AccessAsUser.All" // Only needed for IMAP
//"https://outlook.office.com/POP.AccessAsUser.All", // Only needed for POP
//"https://outlook.office.com/SMTP.AccessAsUser.All", // Only needed for SMTP
};
var cancellationToken = new CancellationToken();
var authToken = await publicClientApplication
.AcquireTokenInteractive(scopes)
.ExecuteAsync(cancellationToken);
await publicClientApplication
.AcquireTokenSilent(scopes, authToken.Account)
.ExecuteAsync(cancellationToken);
SaslMechanism oauth2;
if (client.AuthenticationMechanisms.Contains("OAUTHBEARER"))
{
oauth2 = new SaslMechanismOAuthBearer(authToken.Account.Username, authToken.AccessToken);
}
else
{
oauth2 = new SaslMechanismOAuth2(authToken.Account.Username, authToken.AccessToken);
}
await client.AuthenticateAsync(oauth2);
await client.DisconnectAsync (true);
This line triggers a browser window to open https://login.microsoftonline.com/:
var authToken = await publicClientApplication
.AcquireTokenInteractive(scopes)
.ExecuteAsync(cancellationToken);
This console application will be run unattended. How do I obtain the token and authenticate without a web browser opening up?
This is an answear to your latest comment, as it's my final recommendation. So, first of all, you should decide if you want to acess the data on behalf of user, or as an app granted permissions by admin.
First step is to register your app.
Second step is getting the acess token. This is going to differ based on the method you chose. Tutorial for each: acting on behalf of the user or acting without the user, but granted permission from admin.
Once you have the acess token, you can call the Microsoft Graph API. The important thing is, you always have to call Microsoft Graph API. There is no other official way (as far as I know) of comunicating with Microsoft's services. You can try the requests with the Microsoft Graph Explorer, however it's VERY limited with it's defaul urls/parameters, so I suggest taking a look at the docs.
From what you've described, you first want to obtain UserID. The way of doing this is going to vary based on what type of auth you chose.
If you chose to act on behalf of user, you should be able to get that (ID) using this endpoint: https://graph.microsoft.com/v1.0/me/
If you chose to act as an app with admin consent, you should be able to search for user using the https://graph.microsoft.com/v1.0/me/people/?$search= with search query parameters. Here are the docs for this endpoint
Now, the only thing left, is to supply that ID to one of the Outlook api methods. You can find docs for them here. Specifically, it seems like you want to list all messages and then read a specific message.
Also, keep an eye on what methods you use with which type of auth. On behalf of user, you usually want url's that contain /me, on behalf of app with given admin privelages, you usually want some endpoint that enables you to pass user id.
Hope I helped!
PS: There is no code in this response, because there is a lot of stuff that just cannot be coded without your decisions, actions on Azure and so on. I suggest you read a little bit about auth and graph api using microsoft docs I linked earlier.
This code worked for me using MSAL after registering the app in azure and getting a client secret.
var options = new ConfidentialClientApplicationOptions
{
ClientId = "<ClientID or Application ID>",
TenantId = "<Azure TenantId>",
RedirectUri = "http://localhost"
};
string clientSecret = "<Client Secret Goes here>";
var confidentialClientApplication = ConfidentialClientApplicationBuilder
.CreateWithApplicationOptions(options)
.WithClientSecret(clientSecret)
.Build();
var scopes = new string[] {
"https://outlook.office365.com/.default"
};
var authToken = await confidentialClientApplication.AcquireTokenForClient(scopes).ExecuteAsync();
We are working on a system to automatically commit generated projects into Git repositories located in Azure Devops. We want to use libgit2sharp for this. We want the user to authenticate using their Microsoft account, grab the Access Token(jwt) from the authentication request and use that as means of authentication. But we cannot seem to get this working.
In another post I read 2 other authentication methods: 1. Alternative accounts. 2. Personal Access Tokens, PAT. Both made in the profile sections of your devops account.
I can get Alternative accounts to work perfectly but this is not our preferred route as it will require extra actions from the user. The PAT does not seem to work for me and throws me an error that there were "too many redirects or authentication replays". I figured this is because of the two factor authentication that is enabled on the Microsoft account.
Is it even supported to use an Access Token(jwt) in LibGit2Sharp with 2FA enabled?
using (var repo = new Repository({repo location}))
{
foreach (var file in file)
{
repo.Index.Add(file.Path);
repo.Index.Write();
}
var author = new Signature("{name}", "{name}", DateTime.Now);
var committer = author;
repo.Commit("Here's a commit i made!", author, committer);
var options = new PushOptions();
options.CredentialsProvider = (url, user, cred) => new UsernamePasswordCredentials() { Username = "{username}", Password = "{password}" };
repo.Network.Push(repo.Branches["master"], options);
}
Personal Access Tokens (PAT) do bypass MFA so that is probably not the error you're getting. A PAT is your best option, at the moment of the push you need the remote-url of your local Git repo to be as follows:
https://pat:{PAT_HERE}#dev.azure.com/...
e.g.
https://pat:gaakbfootuial7ksj4uv55o52335tyhhaasbqdvbg5xgyy33t754#dev.azure.com/auroraloop/devenv/_git/devenv
Tips:
The PAT will take the permissions of the Azure DevOps user that generated it so the user must have contribute permissions to the repo.
You cannot automate PAT creation, you must have it upfront stored somewhere, if you don't want to hardcode this (you shouldn't) consider using an Azure Key Vault to store and retrieve the value I'm sure they have c# libraries.
The options.CredentialsProvider part of your code is probably doing exactly what I mentioned about the remote-url try setting it as follows:
options.CredentialsProvider = (url, user, cred) => new UsernamePasswordCredentials() { Username = "pat", Password = "{PAT_HERE}" };
Hardcode the PAT for testing and if successful take a look at the Azure Key Vault approach.
I am creating a console application that connects to Microsoft Graph using the Microsoft Graph API (as shown in https://github.com/microsoftgraph/console-csharp-connect-sample).
Everything is working fine, but I wonder if there is a way where I can authenticate a user (when I already know their user/password) without them needing to manually enter their credentials on the "Sing in to your account" window rendered on the desktop.
The idea is basically to run the application unattended, so there is no need for the user to be entering their credentials when the application starts. I can´t find any relevant information on the subject.
Is that even possible?
EDIT
After following the link #DanSilver posted about geting access without a user, I tried the sample suggested in that link (https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2). Although that is an MVC application that forces users to authenticate (precisely what I wanted to avoid) I have managed to use part of the authentication code in that sample with my console application. After giving authorization to the application manually through a request to https://login.microsoftonline.com/myTenantId/adminconsent I can create a GraphServiceClient in my console app that connects to Graph without user interaction. So I mark the answer as valid.
Just in case someone is in the same situation, the GraphServiceclient is created as:
GraphServiceClient graphServiceClientApplication = new GraphServiceClient("https://graph.microsoft.com/v1.0", new DelegateAuthenticationProvider(
async (requestMessage) =>
{
string clientId = "yourClientApplicationId";
string authorityFormat = "https://login.microsoftonline.com/{0}/v2.0";
string tenantId = "yourTenantId";
string msGraphScope = "https://graph.microsoft.com/.default";
string redirectUri = "msalXXXXXX://auth"; // Custom Redirect URI asigned in the Application Registration Portal in the native Application Platform
string clientSecret = "passwordGenerated";
ConfidentialClientApplication daemonClient = new ConfidentialClientApplication(clientId, String.Format(authorityFormat, tenantId), redirectUri, new ClientCredential(clientSecret), null, new TokenCache());
AuthenticationResult authResult = await daemonClient.AcquireTokenForClientAsync(new string[] { msGraphScope });
string token = authResult.AccessToken;
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", token);
}
));
One idea is using the "app only" authorization flow. The idea is that you can have long running apps access the Microsoft Graph without user authentication. The main difference is instead of the access token granting access to a particular user, it grants your app access to resources that you've consented to in advance. There will be no user login dialog and you can programmatically fetch access tokens to call the Graph API.
To reiterate that these tokens aren't for a particular user, consider making a GET request to 'https://graph.microsoft.com/v1.0/me'. This will return an error since the access token isn't for a particular user and "me" doesn't mean anything. Requests should be sent with full user ids "like graph.microsoft.com/users/someuser#contosos.com".
More information on this can be found at the Get access without a user documentation page.
Another idea is to let the user authenticate the first time they use your app and then store a refresh token. These tokens live longer (a few months IIRC) and then you won't need to prompt for user consent each time the app runs. Refresh tokens can be exchanged for access tokens that live 60 minutes and those can be used to call Graph API on behalf of users.
More info on refresh tokens: https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user#5-use-the-refresh-token-to-get-a-new-access-token
I did want to come back out here and share, since I ran into this problem yesterday, and the idea of granting read/write mailbox access for my application... to EVERYONE'S EMAIL BOX IN THE ENTIRE ORGANIZATION... was way over the top for my needs. (And that is exactly what happens when you start talking about granting Application level permissions instead of delegated permissions to your registered app).
It's a simple use case: I had a nightly process that needed to automate sending of emails from a shared mailbox using a traditional AD service account.
Thankfully... even though they are on the march to eliminate passwords (lol)... someone at Microsoft still recognizes my use case, and it's lack of apples-to-apples alternatives in Azure AD. There is still an extension method we can lean on to get the job done:
private AuthenticationContext authContext = null;
authContext = new AuthenticationContext("https://login.microsoftonline.com/ourmail.onmicrosoft.com",
new TokenCache());
result = authContext.AcquireTokenAsync("https://graph.microsoft.com/",
"12345678-1234-1234-1234-1234567890",
new UserPasswordCredential(
Environment.GetEnvironmentVariable("UID", EnvironmentVariableTarget.User),
Environment.GetEnvironmentVariable("UPD", EnvironmentVariableTarget.User)
)).Result;
You can replace those GetEnvironmentVariable calls with your Username (UID) and Password (UPD). I just stuff them in the environment variables of the service account so I didn't have to check anything into source control.
AcquireTokenAsync is an extension method made available from the Microsoft.IdentityModel.Clients.ActiveDirectory namespace. From there, it's a simple business to fire up a GraphClient.
string sToken = result.AccessToken;
Microsoft.Graph.GraphServiceClient oGraphClient = new GraphServiceClient(
new DelegateAuthenticationProvider((requestMessage) => {
requestMessage
.Headers
.Authorization = new AuthenticationHeaderValue("bearer", sToken);
return Task.FromResult(0);
}));
The last bit of magic was to add these permissions to Application registration I created in Azure AD (where that GUID came from). The application has be defined as a Public client (there's a radio button for that towards the bottom of the authentication tab). I added the following 5 DELEGATED permissions (NOT application permissions):
Microsoft Graph
1. Mail.ReadWrite.Shared
2. Mail.Send.Shared
3. User.Read
4. email
5. openid
Since user consents are actually blocked in our organization, another permissions admin had to review my application definition and then do an admin level grant of those rights, but once he did, everything lit up and worked like I needed: limited access by a service account to a single shared mailbox, with the actual security of that access being managed in Office 365 and not Azure AD.
I am trying to build a list of emailadresses of all employees in our company.
This is in a Web App running on Azure, with Azure AD authentication. The app uses .NET Framework 4.6, and uses the Microsoft.Owin.Security packages to connect to Azure AD.
I can authenticate, I am authorized by my role as defined in the app registration. So far so good.
I can check out my own User Profile. This uses the Microsoft.Azure.ActiveDirectory.GraphClient package to build the queries, instead of manually creating the HTTPRequests.
string userObjectID = ClaimsPrincipal.Current
.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
ActiveDirectoryClient activeDirectoryClient = new ActiveDirectoryClient(serviceRoot,
async () => await authorizationHelper.GetTokenForApplication());
var result = await activeDirectoryClient.Users
.Where(u => u.ObjectId.Equals(userObjectID))
.ExecuteAsync();
IUser user = result.CurrentPage.ToList().First();
AD computes my query, sees that it only returns me, and deduces that I am allowed to view my own info. Execute succeeds, returning just me.
On a different page, I want to show the mail addresses used in the company (to tag a user, to typeahead, to check for existance, etc.) I try the following:
result = await activeDirectoryClient.Users
.ExecuteAsync();
return result.CurrentPage
.ToList();
This fails, "insufficient privileges". I am not allowed to view the entire User I guess. My delegated permissions are to "Read all users' basic profiles", meaning:
Allows the app to read the basic profile of all users in the
organization on behalf of the signed-in user. The following properties
comprise a user’s basic profile: display name, first and last name,
photo, and email address.
So, I try to filter:
result = await activeDirectoryClient.Users
.Where(u => u.Mail.StartsWith(str))
.ExecuteAsync();
return result.CurrentPage
.ToList();
but that still gives me the entire User, and I'm yet again hit with "insufficient privileges". So I try
result = await activeDirectoryClient.Users
.Where(u => u.Mail.StartsWith(str))
.Select (u => u.Mail)
.ExecuteAsync();
return result.CurrentPage
.ToList();
Which gives the cryptic runtime error (free translation from Dutch)
GenericArguments[1], System.String, Microsoft.Azure.ActiveDirectory.GraphClient.Extensions
.ReadOnlyQueryableSet.`2[TSource,TISource] conflicts with type TISource.
And I am at a loss. No source code seems to be available for ActiveDirectoryClient, and the usual Graph API doesn't even mention selecting only basic info.
The "easy" solution would be "just get more app permissions", but that needs a lot of time to go through the bureaucracy. And I SHOULD be able to get all Users' mail, right?
First and foremost, you don't need to do anything special to "Query only basic UserInfo from Azure AD with limited permissions". You just query Users, and it will initialize any fields you do not have access to as null. Insufficient privileges means you're not allowed to look at the user at all. Red flag.
At first I thought my tokencache was faulty. Which it was. Then I fixed it. Still errors.
By looking at several tokens in different applications with the online tool linked by Nan Yu I found out I was missing the actual permission to look at users' basic profiles in my token.
I still didn't get the permission in the token, and found out that even though the checkbox under "Delegated Permissions" was checked, the "Grant Permissions" option was not succesfully used afterwards.
PSA: don't assume all checked boxes are actually granted. Check in the App Service which permissions it has. If you're allowed that by your company, that is.
I'm trying to create web page that access the (business) private calendar of the company and insert events if the time slot is available. Still I'm facing an authentication problem.
The API manual states that I should use an API key and Oauth2LeggedAuthenticator, so I did all this and the request that is fired is quite okey (it has a oauth token and such) But still the response is an exception with Invalid Credentials; Easy to say is that my credentials are wrong, still clientID, clientSecret and API Key are valid; I doubt the 2 last params of the 2legged authenticater, is this correct?
var provider = new NativeApplicationClient(GoogleAuthenticationServer.Description);
provider.ClientIdentifier = ClientCredentials.ClientID;
provider.ClientSecret = ClientCredentials.ClientSecret;
var authenticator =
new OAuth2LeggedAuthenticator(ClientCredentials.ClientID, ClientCredentials.ClientSecret, "myworkusername", "workdomain.com");
Google.Apis.Calendar.v3.CalendarService service = new Google.Apis.Calendar.v3.CalendarService(authenticator);
service.Key = ClientCredentials.ApiKey;
var result = service.CalendarList.List().Fetch();
Assert.IsTrue(result.Items.Count > 0);
NB: At the time of writing you can only used 2-legged authentication with Google Apps for Business/Eduction, this won't work on personal accounts as there's no way to get an OAuth 1.0 key/secret pair, you will have to use online authentication at least once (but you can use the out-of-browser option so you don't have to create a dedicated page).
Your code is correct apart from you don't need the first three lines relating to the NativeApplicationClient. This is most likely failing because you haven't properly set the OAuth keys, this causes 401s.
The other thing that causes 401s is using "matt#example.com" instead of "matt" as the username, the username is without including your domain.
To setup OAuth follow the instructions in this article from Google.
The most important parts to note are "Allow access to all APIs" must be unchecked and you have to individually grant access to all the APIs. If this hasn't been done you will get a 401 Invalid Credentials error. You then also need to turn those services on in the api console. If the api console step hasn't been done you will get a different error of 403 Daily Limit Exceeded.
This will cause you problems if you were previously relying on the "Allow access to all APIs" to use various services, you will have to grant them all individually as far as I understand it to use the v3 APIs. This seems to have been confirmed by google (4th reply by Nicolas Garnier) and is supposedly a bug, but that is an old post so it looks as if it's here to stay.
For reference once this has been done, this code will work, which in essence is the same as yours:
var auth = new OAuth2LeggedAuthenticator(domainName, consumerSecret, usernameWithoutDomain, domainName); //domainName is presently used as the OAuth ConsumerKey for Google's 2legged OAuth
var service = new CalendarService(auth);
service.Key = serviceKey;
var results = service.CalendarList.List().Fetch();
Console.WriteLine(results.Items.Count);
So in summary:
In Google Apps "Manage this Domain" > "Advanced Tools"
Using "Manage OAuth domain key" enable key, generate secret, uncheck "Allow access to all APIs".
Using "Manage third party OAuth Client access" enable the APIs you want access to using your domain as "Client Name" and the APIs you want to access e.g. "http://www.google.com/calendar/feeds/" for the calendar.
Then finally create a project in the API console, use the APIKey as the serviceKey in the above example and turn on the APIs you need to access.
I am answering this as I kept hitting this question when I was trying to find out why my code was constantly returning 401s. Hope this helps someone as the Google instructions are awful and scattered all over the place at the moment.