I am connecting to Graph API with Microsoft Identity Web (MSAL) library.
[https://github.com/AzureAD/microsoft-identity-web][1]
For this I am using client credentials flow with certificate based authentication.
My configurations are below
Service Registration
services.AddMicrosoftIdentityWebApiAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi()
.AddMicrosoftGraph(Configuration.GetSection("DownstreamApi"))
.AddInMemoryTokenCaches();
appSettings.json
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"Domain": "mydomain.onmicrosoft.com",
"TenantId": "xxxxxxx",
"ClientId": "yyyyyyyy",
"ClientCertificates": [
{
"SourceType": "Path",
"CertificateDiskPath": "c:\\cert\\my-cert.pfx",
"CertificatePassword": "password"
}
] }
For this I am getting the below error
IDW10104: Both client secret and client certificate cannot be null or
whitespace, and only ONE must be included in the configuration of the
web app when calling a web API. For instance, in the appsettings.json
file.
However I am able to accrue token and connect with Graph API using Microsoft.Identity.Client (Using client credentials-flow with certificate based auth)
private GraphServiceClient GetGraphServiceClient()
{
var token = GetToken();
GraphServiceClient graphServiceClient =
new GraphServiceClient(new DelegateAuthenticationProvider(async (requestMessage) =>
{
// Add the access token in the Authorization header of the API request.
requestMessage.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", token);
})
);
return graphServiceClient;
}
private string GetToken()
{
var x509Certificate2 =
new X509Certificate2(System.IO.File.ReadAllBytes("MyCert.pfx"), "password");
IConfidentialClientApplication app =
Microsoft.Identity.Client.ConfidentialClientApplicationBuilder.Create("my-client-id")
.WithTenantId("my-tenent-id")
.WithCertificate(x509Certificate2)
.Build();
// With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the
// application permissions need to be set statically (in the portal or by PowerShell), and then granted by
// a tenant administrator
string[] scopes = new string[] { "https://graph.microsoft.com/.default" };
AuthenticationResult result =
app.AcquireTokenForClient(scopes)
.ExecuteAsync().Result;
return result.AccessToken;
}
Am I missing any configuration here?
On workaround
Try with the adding the certificate in the Azure App registration
1) Go to the Azure portal. In the left-hand navigation pane, select the Azure Active Directory service, and then select App registrations.
2) In the resultant screen, select the Select the your application.
3) In the Certificates & secrets tab, go to Certificates section:
4) Select Upload certificate and, in select the browse button on the right to select the your existing certificate.
5) Select Add.
For more details refer this document: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/4-WebApp-your-API/4-1-MyOrg/README-use-certificate.md
Related
I have used Visual Studio's latest New Project wizard to create a ASP Core 2.0 Web page (Razor Pages) that uses Individual Accounts as my authentication option. I have created an Azure AD B2C tenant and validated that it works properly.
When I run the web application that was created by the wizard and click Log In in the upper right, it redirects to my Azure AD B2C site, and I can properly login.
After login, the callback url goes to the endpoint configured in my user secrets:
...
"CallbackPath": "/signin-oidc",
...
That all seems to work properly. I understand that the Azure AD B2C portal sends a token back to the above /signin-oidc callback path and stores it.
How can I retrieve the value of that token?
I've been following all of the Azure AD B2C guides, but not all of them have been updated to ASP Core 2.0, and none of them seem to use the code generated from the 15.4 VS wizard such:
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(sharedOptions =>
{
sharedOptions.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
sharedOptions.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddAzureAdB2C(options => Configuration.Bind("AzureAdB2C", options))
.AddCookie();
services.AddMvc();
}
Note: the .AddAzureAdB2C(...)
None of the B2C samples are using this so its difficult for me to follow.
My end goal is to get the token and use that in a strongly-typed set of API classes I generated from Swagger using Autorest which require the token.
The best way to do this is outlined in the Azure AD B2C .Net Core sample, specifically the branch for Core 2.0.
In the normal model/flow, your application will get an id_token and an authorization code but not a token. The authorization code needs to be exchanged for a token by your middle tier. This token is what you'd then be sending over to your web API.
The way to do this involves the following:
Ensure your middle tier is requesting id_token+code for your primary policy (you don't want to do this for your edit profile or password reset policies). From the sample's OpenIdConnectOptionsSetup.cs#L77:
public Task OnRedirectToIdentityProvider(RedirectContext context)
{
var defaultPolicy = AzureAdB2COptions.DefaultPolicy;
if (context.Properties.Items.TryGetValue(AzureAdB2COptions.PolicyAuthenticationProperty, out var policy) &&
!policy.Equals(defaultPolicy))
{
context.ProtocolMessage.Scope = OpenIdConnectScope.OpenIdProfile;
context.ProtocolMessage.ResponseType = OpenIdConnectResponseType.IdToken;
context.ProtocolMessage.IssuerAddress = context.ProtocolMessage.IssuerAddress.ToLower().Replace(defaultPolicy.ToLower(), policy.ToLower());
context.Properties.Items.Remove(AzureAdB2COptions.PolicyAuthenticationProperty);
}
else if (!string.IsNullOrEmpty(AzureAdB2COptions.ApiUrl))
{
context.ProtocolMessage.Scope += $" offline_access {AzureAdB2COptions.ApiScopes}";
// -----------------------------
// THIS IS THE IMPORTANT PART:
context.ProtocolMessage.ResponseType = OpenIdConnectResponseType.CodeIdToken;
// -----------------------------
}
return Task.FromResult(0);
}
Exchange the code for a token. From the sample's OpenIdConnectOptionsSetup.cs#L103-L124:
public async Task OnAuthorizationCodeReceived(AuthorizationCodeReceivedContext context)
{
// Use MSAL to swap the code for an access token
// Extract the code from the response notification
var code = context.ProtocolMessage.Code;
string signedInUserID = context.Principal.FindFirst(ClaimTypes.NameIdentifier).Value;
TokenCache userTokenCache = new MSALSessionCache(signedInUserID, context.HttpContext).GetMsalCacheInstance();
ConfidentialClientApplication cca = new ConfidentialClientApplication(AzureAdB2COptions.ClientId, AzureAdB2COptions.Authority, AzureAdB2COptions.RedirectUri, new ClientCredential(AzureAdB2COptions.ClientSecret), userTokenCache, null);
try
{
AuthenticationResult result = await cca.AcquireTokenByAuthorizationCodeAsync(code, AzureAdB2COptions.ApiScopes.Split(' '));
context.HandleCodeRedemption(result.AccessToken, result.IdToken);
}
catch (Exception ex)
{
//TODO: Handle
throw;
}
}
You can then use this token elsewhere in your code to call an API. From the sample's HomeController.cs#L45-L57:
var scope = AzureAdB2COptions.ApiScopes.Split(' ');
string signedInUserID = HttpContext.User.FindFirst(ClaimTypes.NameIdentifier).Value;
TokenCache userTokenCache = new MSALSessionCache(signedInUserID, this.HttpContext).GetMsalCacheInstance();
ConfidentialClientApplication cca = new ConfidentialClientApplication(AzureAdB2COptions.ClientId, AzureAdB2COptions.Authority, AzureAdB2COptions.RedirectUri, new ClientCredential(AzureAdB2COptions.ClientSecret), userTokenCache, null);
AuthenticationResult result = await cca.AcquireTokenSilentAsync(scope, cca.Users.FirstOrDefault(), AzureAdB2COptions.Authority, false);
HttpClient client = new HttpClient();
HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, AzureAdB2COptions.ApiUrl);
// Add token to the Authorization header and make the request
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
HttpResponseMessage response = await client.SendAsync(request);
The ASP.NET Core team has created 2 excellent documents on this process.
Cloud authentication with Azure Active Directory B2C in ASP.NET Core
Use Visual Studio to create an ASP.NET Core web app configured to use the Azure AD B2C tenant for authentication
Cloud authentication in web APIs with Azure Active Directory B2C in ASP.NET Core
Use Visual Studio to create a Web API configured to use the Azure AD B2C tenant for authentication
We have two Application registered in the same AAD B2C tenant via "New" and "Old" portal.
Authentication with "Old" Application credentials works correct.
With "New" Application credentials - error appears:
IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier: 'SecurityKeyIdentifier
(
IsReadOnly = False,
Count = 1,
Clause[0] = System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause
)
'
Is it right way to use Microsoft.Owin.Security.ActiveDirector library (to protect ASP.Net Web API) with Application registered in AAD B2C tenant.
P.S. My question is based on this post.
You should only create applications via the Azure AD B2C blade in the new Azure portal (portal.azure.com).
Do NOT create applications for Azure AD B2C using the classic Azure Portal (manage.windowsazure.com).
If you want to secure a WebApp, you should use Owin's OpenIdConnectAuthentication. This document has more details on how to do this: Sign-Up & Sign-In in a ASP.NET Web App
If you want to secure a WebAPI, you should use Owin's OAuthBearerAuthentication. This document has more details on how to do this: Build a .NET web API
Samples configuration of a WebApp:
public void ConfigureAuth(IAppBuilder app)
{
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
// Generate the metadata address using the tenant and policy information
MetadataAddress = String.Format(AadInstance, Tenant, DefaultPolicy),
// These are standard OpenID Connect parameters, with values pulled from web.config
ClientId = ClientId,
RedirectUri = RedirectUri,
PostLogoutRedirectUri = RedirectUri,
// Specify the callbacks for each type of notifications
Notifications = new OpenIdConnectAuthenticationNotifications
{
RedirectToIdentityProvider = OnRedirectToIdentityProvider,
AuthorizationCodeReceived = OnAuthorizationCodeReceived,
AuthenticationFailed = OnAuthenticationFailed,
},
// Specify the claims to validate
TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name"
},
// Specify the scope by appending all of the scopes requested into one string (separated by a blank space)
Scope = $"{OpenIdConnectScopes.OpenId} {YourScope1} {YourScope2}"
}
);
}
Samples configuration of a Web API:
public void ConfigureAuth(IAppBuilder app)
{
TokenValidationParameters tvps = new TokenValidationParameters
{
// Accept only those tokens where the audience of the token is equal to the client ID of this app
ValidAudience = ClientId,
AuthenticationType = Startup.DefaultPolicy
};
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions
{
// This SecurityTokenProvider fetches the Azure AD B2C metadata & signing keys from the OpenIDConnect metadata endpoint
AccessTokenFormat = new JwtFormat(tvps, new OpenIdConnectCachingSecurityTokenProvider(String.Format(AadInstance, Tenant, DefaultPolicy)))
});
}
Currently, I am integrating Azure Active Directory into my .NET Web API using following code:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = WebConfigurationManager.AppSettings["AzureClientId"],
Tenant = WebConfigurationManager.AppSettings["AzureTenant"]
}
});
The audience and tenant were set in web.config file.
I can get the token correctly and users can log in using their azure AD account.
However, I moved the audience and tenant to database to allow users to change the settings and disable/enable azure login by UI instead of changing the setting in web.config.
The above code was changed to:
var azureSetting = db.GetAzureSetting();
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = azureSetting.AzureClientId,
Tenant = azureSetting.AzureTenant
}
});
When the app first starts, there is no config in the database because users do not enter the config yet. Then users go to azure config screen, enter the correct Client Id, Tenant, Client Secret. But users can not log in using azure AD user.
Can anyone explain this case for me?
Is there any way to save azure config in db instead of web.config?
Your code in the post works when web API start and we can’t change configuration runtime , if you want to enable users change the audience and tenant dynamically, you could handle token validation yourself . You could use JwtSecurityTokenHandler to validate the token after your api app get the access token , code below is for your reference :
public JwtSecurityToken Validate(string token)
{
string stsDiscoveryEndpoint = "https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration";
ConfigurationManager<OpenIdConnectConfiguration> configManager = new ConfigurationManager<OpenIdConnectConfiguration>(stsDiscoveryEndpoint);
OpenIdConnectConfiguration config = configManager.GetConfigurationAsync().Result;
TokenValidationParameters validationParameters = new TokenValidationParameters
{
ValidateAudience = true,
ValidateIssuer = false,
ValidAudience = "https://testbasic1.onmicrosoft.com/TodoListService", //your value from database
IssuerSigningTokens = config.SigningTokens,
ValidateLifetime = false
};
JwtSecurityTokenHandler tokendHandler = new JwtSecurityTokenHandler();
SecurityToken jwt;
var result = tokendHandler.ValidateToken(token, validationParameters, out jwt);
return jwt as JwtSecurityToken;
}
This handler helps you verify the signature of the token to ensure the token was issued by Azure Active Directory,and also verify the claims in the token based on the business logic,in your scenario,you need to confirm audience and tenant.
In you web api app , you could register custom TokenValidationHandler in Global.asax :
GlobalConfiguration.Configuration.MessageHandlers.Add(new TokenValidationHandler());
You could click here for code sample , you could modify your code to check whether tokens comes from tenant-id which stores in database .
We are successfully authenticating the Azure AD users from different subscription using Azure AD Multi-tenant application but unable to authenticate the Windows Live ID accounts.
To authenticate the live ID accounts we use the Windows Live ID identity provider with Azure Access Control Service (ACS), its working fine with Azure AD single tenant application but we are struggling to authenticate Azure AD users across subscriptions which can only be done by using the Azure AD multi-tenant application.
We follow this blog https://msdn.microsoft.com/en-us/library/azure/dn486924.aspx and it works for Single tenant application but when we try to configure the Azure AD app to multi-tenant and configure it with ACS getting the below error.
enter image description here
Is there any approach we authenticate the Windows Live ID and use the Azure Multi-Tenant Application?
You can authenticate Microsoft Account (live id) users in a multi tenant application by skipping ACS altogether and provisioning the Microsoft Account in directory tenants. One gotcha is that authenticating with a Microsoft Account requires you to fully specify the authentication endpoints by instantiating the tenant in the URL. You cannot use the /common endpoint because that relies on the user's home tenant, and an MSA user does not have one.
You add following code in your Account controller
public void SignIn(string directoryName = "common")
{
// Send an OpenID Connect sign-in request.
if (!Request.IsAuthenticated)
{
HttpContext.GetOwinContext().Environment.Add("Authority", string.Format(ConfigurationManager.AppSettings["ida:Authority"] + "OAuth2/Authorize", directoryName));
HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/" },
OpenIdConnectAuthenticationDefaults.AuthenticationType);
}
}
and add this block in your startup.auth.cs
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = ClientId,
Authority = Authority,
TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
{
// we inject our own multitenant validation logic
ValidateIssuer = false,
},
Notifications = new OpenIdConnectAuthenticationNotifications()
{
RedirectToIdentityProvider = (context) =>
{
object obj = null;
if (context.OwinContext.Environment.TryGetValue("Authority", out obj))
{
string authority = obj as string;
if (authority != null)
{
context.ProtocolMessage.IssuerAddress = authority;
}
}
if (context.OwinContext.Environment.TryGetValue("DomainHint", out obj))
{
string domainHint = obj as string;
if (domainHint != null)
{
context.ProtocolMessage.SetParameter("domain_hint", domainHint);
}
}
context.ProtocolMessage.RedirectUri = HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path);
context.ProtocolMessage.PostLogoutRedirectUri = new UrlHelper(HttpContext.Current.Request.RequestContext).Action
("Index", "Home", null, HttpContext.Current.Request.Url.Scheme);
//context.ProtocolMessage.Resource = GraphAPIIdentifier;
context.ProtocolMessage.Resource = AzureResourceManagerIdentifier;
return Task.FromResult(0);
},
...
}
When you click on "SignIn" ask for "Azure AD name". Pass that variable to the Account/SignIn action. If the user will be present in the mentioned Azure AD, sign-in will be successful.
The following is in a console application and ClientID, RedirectUri is from the created native app in azure active directory.
var authContext = new AuthenticationContext(string.Format("https://login.windows.net/{0}","common"),new FileCache());
var token = authContext.AcquireToken("https://management.core.windows.net/", ClientID, RedirectUri, PromptBehavior.Auto);
I now have the token for talking with management api.
using (var client = new KeyVaultManagementClient(new TokenCloudCredentials(SubscriptionId, token.AccessToken)))
{
var a = client.Vaults.List(resourceGroup, 10);
foreach(var vault in a.Vaults)
{
var vaultInfo = client.Vaults.Get(resourceGroup, vault.Name);
Console.WriteLine(JsonConvert.SerializeObject(vaultInfo.Vault, Formatting.Indented));
//Verifying that the AccessPolicies contains my object id (pasting idtoken into jwt.io and compare with oid claim) Success.
// Now its time to talk with keyvault
var keyvault = new KeyVaultClient(GetAccessTokenAsync);
var secrets = keyvault.GetSecretsAsync(vaultInfo.Vault.Properties.VaultUri).GetAwaiter().GetResult();
}
}
private static Task<string> GetAccessTokenAsync(string authority, string resource, string scope)
{
var context = new AuthenticationContext(authority, new FileCache());
var result = context.AcquireToken(resource, new ClientCredential(AppClientId,AppKey));
return Task.FromResult(result.AccessToken);
}
Above works but require me to create a separate app on my AD that can talk with the keyvault. I would like to use my own ID to talk with keyvault, but I cant figure out how to get the access token that the keyvault client require.
Do i need to update the manifest on azure manuel and adding that my console app is allowed to get a token on behalf of users to keyvault?
What code is needed to be changed in GetAccessTokenAsync to make it work.
I have tried giving it just the access or id tokens from the initial token request from the common endpoint. Do anyone have some suggestions on how to talk to azure key vault on behalf of my own id and not an app?
Update
So looking at headers i found out my token was missing vault.azure.net as resource and therefore trying:
var testtoken = authContext.AcquireToken("https://vault.azure.net", ClientID, RedirectUri);
gives the following error:
AADSTS65005: The client application has requested access to resource
'https://vault.azure.net'. This request has failed because the client
has not specified this resource in its requiredResourceAccess list.
and looking at the current manifest:
"requiredResourceAccess": [
{
"resourceAppId": "797f4846-ba00-4fd7-ba43-dac1f8f63013",
"resourceAccess": [
{
"id": "41094075-9dad-400e-a0bd-54e686782033",
"type": "Scope"
}
]
},
{
"resourceAppId": "00000002-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6",
"type": "Scope"
}
]
}
],
How do i know what guids to use for scope and resourceAppId for the keyvault?
Temp Solution
Until i know how to get the resourceAppId and related information I am using the old trick of impersonating the powershell tools.
var vaultToken = authContext.AcquireToken("https://vault.azure.net", "1950a258-227b-4e31-a9cf-717495945fc2", new Uri("urn:ietf:wg:oauth:2.0:oob"));
var keyvault = new KeyVaultClient((_, b, c) => Task.FromResult(vaultToken.AccessToken));
var secrets = keyvault.GetSecretsAsync(vaultInfo.Vault.Properties.VaultUri).GetAwaiter().GetResult();
source: http://www.s-innovations.net/Blog/2014/02/12/Controlling-the-login-flow-when-using-ADAL-for-WAML
Please also read #bradygaster comment at the blog post before using the powershells clientid.
You're on the right track! You need to configure AAD to be able to authorize users specifically for access to KeyVault. Try adding the following to your manifest.
{
"resourceAppId": "cfa8b339-82a2-471a-a3c9-0fc0be7a4093",
"resourceAccess": [
{
"id": "f53da476-18e3-4152-8e01-aec403e6edc0",
"type": "Scope"
}
]
}
If that doesn't work, you can do this the old-fashioned way by visiting the old portal, navigating to AAD, your AAD Tenant, your application, and adding "Azure Key Vault" under the "permissions to other applications" section of the "Configure" tab.
Here is what you need to do:
Create a service principal
Register it in Azure AD
Grant it access to the Azure KeyVault API
The steps were documented in an Azure article last September at
https://blogs.technet.microsoft.com/kv/2016/09/17/accessing-key-vault-from-a-native-application/
This article explains how to perform the above steps to access Azure KeyVault programmatically from a native application (as opposed to a service application) without having to rely on the Azure Powershell trick mentioned by #benv.