I'm trying to get Microsoft configured as an external login provider in Identityserver4.
I succeeded by following identity server's documentation with using AddMicrosoftAccount:
services.AddAuthentication().AddMicrosoftAccount(microsoftOptions =>
{
microsoftOptions.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
microsoftOptions.ClientId = configuration["MicrosoftLoginProvider:ClientId"];
microsoftOptions.ClientSecret = configuration["MicrosoftLoginProvider:ClientSecret"];
});
However, I didn't have luck with getting single sign-out to work. The documentation is in line with Microsoft's documentation at https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-5.0.
However, if you follow the instructions to create an app in Microsoft Developer Portal (portal.azure.com), the sample code on that portal suggests a different way. The sample application that the portal generated for me (WebApp-OpenIDConnect-DotNet) is using AddMicrosoftIdentityWebApp:
services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));
Since this application is working out-of-the-box including single sign-out, Iam wondering if this is the way I have to continue.
To my surprise, however, I can't find any doc/blogs about how to integrate this approach in IdentityServer4. I almost got it to work myself, but there are a few weird issues.
Can someone clarify if using AddMicrosoftIdentityWebApp is the way to go to add Microsoft as an external identity provider to Identityserver4?
Has someone succeeded in getting AddMicrosoftIdentityWebApp to work with IdentityServer4?
THanks for your help!
I figured how to get it to work.
Actually, only two things I had to do.
First, I had to remove OpenIdConnectDefaults.AuthenticationScheme in the call to AddAuthentication in the example code that Microsoft generated. So the code becomes:
services.AddAuthentication()
.AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));
Then, in the code that reads the external identity from a temporary cookie, I had to use CookieAuthenticationDefaults.AuthenticationScheme. So, that code now reads as follows:
var authenticationResult = await HttpContext.AuthenticateAsync(CookieAuthenticationDefaults.AuthenticationScheme);
That was all.
After digging around I found this statement here:
Microsoft.Identity.Web is a simpler way to use Azure AD in ASP.NET Core web apps and web APIs.
It doesn't replace ASP.NET Identity in any way, it doesn't replace AddJwtBearer or AddCookie or any of the lower level primitives, but it does use and configure them correctly for Azure AD.
It doesn't work with non-Azure identity providers. It replaces AzureAD.UI and AzureADB2C.UI which are obsolete in .NET 5.0
So, the conclusion is that Microsoft.Identity.Web does not work outside Azure AD and hence not with IdentityServer.
If you do get it to work then let me know!
Related
I’m new at Azure. So i’ve developed a simple Web app in net core 6 which autenticathes with AZ AD.
I also add to my solución an azure function but the idea is to add JWT to it .
From azure portal i added, authentication but i dont know how to get a token to , for example, test it with postman.
Does someone know how to do this? I’ve Watch a lot of videos but still can’t get it .
Regards
i need help to add security to my az function and be able to add jwt to my web app and to try tokens from postman.
I tried to reproduce the same in my environment and got the results like below:
Create an Azure AD Application and add API permissions:
Generate the Auth-Code by using below Endpoint:
https://login.microsoftonline.com/TenantID/oauth2/v2.0/authorize?
client_id=ClientID
&response_type=code
&redirect_uri=RedirectURI
&response_mode=query
&scope=[https://management.azure.com/.default](https://management.azure.com/.default "https://management.azure.com/.default")
&state=12345
To generate the token, I used the below parameters:
GET https://login.microsoftonline.com/TenantId/oauth2/v2.0/token
client_id:ClientID
client_secret:ClientSecret
scope:https://management.azure.com/.default
grant_type:authorization_code
redirect_uri:RedirectUri
code:code
By using the above generated access token, you can access Azure Function successfully like below:
GET https://management.azure.com/subscriptions/SubID/resourceGroups/RG/providers/Microsoft.Web/sites/funcapp/functions/function?api-version=2022-03-01
I have an ASP.NET Core 3.1 Web App calling an ASP.NET Core 3.1 Web API, which in turn accesses an Azure SQL database. Authentication is provided via MSAL (Microsoft Identity Platform) - i.e. using the relatively new Microsoft.Identity.Web and Microsoft.Identity.Web.UI libraries.
The goal is to ensure that the user pulls data from SQL via the API under the context of his/her own login, thus enabling row-level security, access auditing and other good things.
I have succeeded in getting the sign-in process to work for the Web App - and through that it obtains a valid access token to access the API using a scope I created when registering the latter with AD.
When I run both the API and the App locally from Visual Studio everything works as expected - the correct access tokens are provided to the App to access the API, and the API to access SQL - in both cases under the user's (i.e. my) identity.
When I publish the API to App Services on Azure, however, and access it there either from a local version of the Web App or an App-Services hosted version of it, the access token that the API gets to access SQL contains the API's Application Identity (system-assigned managed identity), and not the user's identity. Although I can access SQL as the application, it's not what we need.
The Web App obtains its access token using the GetAccessTokenForUserAsync method of ITokenAcquisition - taking as a parameter the single scope I defined for the API.
The API gets its token (to access SQL) like so:
var token = await new AzureServiceTokenProvider().GetAccessTokenAsync("https://database.windows.net", _tenantId)
...where _tenantId is the tenant ID of the subscription.
I have added the SQL Azure Database "user_impersonation" API permission to the AD registration for the API - but that has not helped. As an aside, for some reason Azure gives the full name of this permission as https://sql.azuresynapse.usgovcloudapi.net/user_impersonation - which is slightly alarming as this is just a UK-based regular Azure account.
I have found a few similar posts to this, but mostly for older versions of the solution set. I'm hoping to avoid having to write my own code to post the token requests - this is supposed to be handled by the MSAL libraries.
Should I somehow be separately requesting a SQL access scope from the Web App after sign-in, or should the API be doing something different to get hold of a SQL access token that identifies the user? Why does it work perfectly when running locally?
It seems like this should be a very common use case (the most common?) but it is barely documented - most documentation I've found refers only to the application identity being used or doesn't tell you what to do for this particular tech stack.
Finally - success! In the end this was the critical piece of documentation: Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow - the key points being:
The App only asks for a token to access the API.
The API then requests a token, on behalf of the user identified via the 1st token, to access SQL.
The key is that - since the API cannot trigger a consent window for the second step - I had to use the Enterprise Applications tab in the Azure portal to pre-grant the permissions for SQL.
So the good news is it does work: maybe it's obvious to some but IMO it took me far too long to find the answer to this. I will write up a fuller explanation of how to do this in due course as it can't only be me struggling with this one.
The bad news is that - in the course of my investigations - I found that Azure B2C (which is the next thing I need to add in) doesn't support this "On Behalf Of" flow - click here for details. That's a great shame as I think it's the most obvious use case for it! Oh well, back to the drawing board.
I'm currently working on a similar problem, using a Net5.0 Web app. The reason it appears to be working locally is you are signed into Visual Studio with a user who can access Azure SQL and those are the rights you get in the Db. The IDE is using those credentials in place of the Managed Service Identity, the latter gets used when you upload the app to Azure.
As you noted, in the App registration you need to grant permission to the App for Azure SQL Database user_impersonation.
In your code, you need to request a token from https://database.windows.net//.default (note the // as it's needed for v1 endpoints). By referencing /.default you are asking for all permissions you've selected for the app in the app registration portal.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope
In Startup.cs you need to EnableTokenAcquisitionToCallDownstreamApi with the scope you require.
services.AddMicrosoftIdentityWebAppAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi(new[]
{"https://database.windows.net//.default"})
// Adds the User and App InMemory Token Cache
.AddInMemoryTokenCaches();
services.AddAuthorization(options =>
{
// By default, all incoming requests will be authorized according to the
// default policy
options.FallbackPolicy = options.DefaultPolicy;
});
services.AddDbContext<MyDatabaseContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("MyAzureConnection")));
// The database interface
services.AddScoped<ITodos, TodoData>();
services.AddRazorPages()
.AddRazorRuntimeCompilation()
.AddMvcOptions(o =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
o.Filters.Add(new AuthorizeFilter(policy));
})
.AddMicrosoftIdentityUI();
You also need to decorate your controllers with [AuthorizeForScopes(Scopes = new string[]{"https://database.windows.net//.default"}] and include the required scopes for that Controller. For Razor, it's at the top of the page model and requires a reference to `using Microsoft.Identity.Web;'
namespace ToDoApp.Pages.Todos
{
[AuthorizeForScopes(ScopeKeySection = "AzureSQL:BaseUrl")]
public class CreateModel : PageModel
I'm using a section in my appsettings.json for the scope and retrieving it using ScopeKeySection:
"AzureSQL": {
"BaseUrl": "https://database.windows.net//.default",
"Scopes": "user_impersonation"
}
This shows you where to include it for MVC, Razor and Blazor:
https://github.com/AzureAD/microsoft-identity-web/wiki/Managing-incremental-consent-and-conditional-access#in-mvc-controllers
Finally, your DbContext needs a token which you could pass to it from the client app (perhaps...).
This is how I am doing it at the moment
public class MyDatabaseContext : DbContext
{
private readonly ITokenAcquisition _tokenAcquisition;
public MyDatabaseContext (ITokenAcquisition tokenAcquisition,
DbContextOptions<MyDatabaseContext> options)
: base(options)
{
_tokenAcquisition = tokenAcquisition;
string[] scopes = new[]{"https://database.windows.net//.default"};
var result = _tokenAcquisition.GetAuthenticationResultForUserAsync(scopes)
.GetAwaiter()
.GetResult();
token = result.AccessToken;
var connection = (SqlConnection)Database.GetDbConnection();
connection.AccessToken = result.token;
}
This is a flawed solution. If I restart the app and try to access it again I get an error Microsoft.Identity.Web.MicrosoftIdentityWebChallengeUserException: IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user
It seems to be related to the TokenCache. If I sign out and in again or clear my browser cache the error is resolved. I've a workaround that signs the app in on failure, but it's deficient since I'm using the app's credentials.
However, it successfully connects to the Azure SQL Db as the user instead of the App with the user's rights instead. When I do solve the error (or find one) I will update this answer.
I am developing an application to be hosted in the Azure App Services environment which consists of a front-end Web App, a back-end Web API and a SQL Database (using Azure SQL). The front-end Web App is a Razor Pages app. We are trying to use the Microsoft Identity Platform (via Microsoft.Identity.Web and Microsoft.Identity.Web.UI libraries) to acquire an access token for the API when needed.
It works perfectly well the first time, but once a token has been acquired and cached - if the application is restarted it fails with this error:
IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user. See https://aka.ms/ms-id-web/ca_incremental-consent.
No account or login hint was passed to the AcquireTokenSilent call.
Startup configuration is (I've tried various variants of this):
public void ConfigureServices(IServiceCollection services)
{
services.AddDistributedMemoryCache();
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
options.HandleSameSiteCookieCompatibility();
});
services.AddOptions();
services.AddMicrosoftIdentityWebAppAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi(new string[] { Configuration["Api:Scopes"] })
.AddInMemoryTokenCaches();
services.AddControllersWithViews(options =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
}).AddMicrosoftIdentityUI();
services.AddRazorPages().AddRazorRuntimeCompilation().AddMvcOptions(options =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
});
services.AddMvc();
//Other stuff...
}
I have tried for many days trying to find either a resolution workaround for this. I can catch the
error, but there is no action we can take programmatically that seems to clear the problem (the ITokenAcquisition interface does not offer the option to force an interactive login).
I have found that it is ONLY a problem in a Razor Pages application - a controller-based MVC Web App with almost identical startup code does not exhibit the problem.
I have also found that, by creating a controller-based test MVC Web App and configuring it with the same client id, tenant id etc. as the app we're having problems with, then starting it up (within the Visual Studio development environment) as soon as the main app gets the problem, I can clear the error condition reliably every time. However this is obviously not a viable long-term solution.
I have searched for this problem on every major technical forum and seen a number of similar sorts of issues raised, but none provides a solution to this precise problem.
To replicate:
Create an ASP.NET Core 3.1 Web API.
Create an ASP.NET Core 3.1 Razor Pages Web App that calls the API.
Register both with Azure Active Directory and configure the App to request a token to access the API (as per various MS documents).
Run - if everything is set up correctly the login screen will appear and all will work correctly.
Stop the Web App, wait a couple of minutes and re-start. The error above will now appear.
I have raised a Microsoft support request for it - has anybody else come across this and found a solution for it?
I have finally got to the bottom of this, largely thanks to this: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/issues/216#issuecomment-560150172
To summarise - for anyone else having this issue:
On the first invocation of the web app you are not signed in, and so get redirected to the Microsoft Identity Platform login, which logs you in and issues an access token.
The access token is stored in the In-Memory token cache through the callback.
All then works as expected because the token is in the cache.
When you stop, and then re-start the web app within a reasonably short time, it uses the authentication cookies to pick up the still-current login, and so it does not access the Identity Platform and you do NOT get an access token.
When you ask for a token the cache is empty - so it throws the MsalUiRequiredException.
What isn't really made clear in any of the documentation is that this is supposed to happen - and that exception is picked up by the "AuthorizeForScopes" attribute but only if you allow the exception to fall all the way through and don't try to handle it.
The other issue is that in a Razor Pages app the normal AuthorizeForScopes attribute has to go above the model class definition for every page - and if you miss one it may trigger the above problem.
The solution proposed by "jasonshave" in the linked article solves that problem by replacing the attribute with a filter - so it will apply to all pages.
Maybe I'm a bit old-school, but the idea of using an unhandled exception as part of a planned program control flow doesn't sit right with me - at the very least it should be made clear that that's the intention. Anyway - problem now solved.
I need to configure Azure Active Directory SSO for Tableau Server gallery app as it is under MS documentation link programmatically. Are there useful powershell cmdlets / rest apis?
I create application from gallery using graph api from Step 1 on MS docs.
To get available templates:
GET https://graph.microsoft.com/beta/applicationTemplates
To create template app:
POST https://graph.microsoft.com/beta/applicationTemplates/{id}/instantiate
Now I need to configure SAML SSO from code and assign users. Is there an easy way to do that? I tried Set-AzureADApplication but it didn't do the job for me. The enterprise application is still not set.
Maybe it's not supported yet? I believe there can be some workaround. I would be grateful for any help.
Are there useful powershell cmdlets / rest apis?
Yes, but per my test, we need to do that into two parts.
1.Set the Sign-on URL, to do this, we need to call Microsoft Graph - Update serviceprincipal.
In the Graph Explorer, use the request below.
PATCH https://graph.microsoft.com/beta/servicePrincipals/<object-id of the service principal>
{
"loginUrl": "https://azure.signtest.link"
}
Note: In the request above, you need to use the object-id of the service principal(Enterprise application), not the AD App(App registeration). You can find it in the Azure AD in the portal -> Enterprise Application -> find your Tableau Server -> get the Object ID like below.
2.Set the Identifier and Reply URL, we could do this via Powershell Set-AzureADApplication.
Sample:
$Identifiers = #(
"http://www.tableau.com/products/server",
"https://azure.idtest.link"
)
$ReplyUrls = #(
"https://azure.rptest.link/wg/saml/SSO/index.html"
)
Set-AzureADApplication -ObjectId <object-id of the AD App> -IdentifierUris $Identifiers -ReplyUrls $ReplyUrls
For the object-id of the AD App, navigate to the Azure AD in the portal -> App registrations -> find your Tableau Server. After running the command, the settings will map to the enterprise application.
Check the result in the portal:
Update:
Not sure if it is a bug, if I create a new app without setting the Identifier and Reply URL manually in the portal, then just use the powershell above to set them, they will not map to the portal.
But if we check the service principal(enterprise application) directly via Microsoft Graph, we can see the powershell actually affected the service principal.
If we configure the settings manually in the portal first, then use the powershell to update them with other values, it works.
And it looks there is no way to set the Default Reply URL via powrshell or API, if we set the Reply URL which is different from the one set manually in the portal, it will have a prompt like below.
But if we look into it, actually the Default option is checked.
Update2:
Eventually, I find the trick, it is not a bug, we just need to set the preferredSingleSignOnMode for the service principal first via Microsoft Graph, then we won't need to configure that in the portal manually.
Sample:
PATCH https://graph.microsoft.com/beta/servicePrincipals/<object-id of the service principal>
{
"preferredSingleSignOnMode":"saml",
"loginUrl": "https://azure.signtest.link"
}
Our authentication system is currently seeing many "Correlation failed" errors for some users trying to connect via Google Sign In. We're using Identity Server 4 / ASP.NET identity with .NET Core 2.2. Obviously, we can't reproduce.
Though we tried to understand every aspect of what we were implementing and deploying, the whole authentication flow and the many configuration possibilities of ASP.NET Identity and IS4 still hold mystery to us. We've tried to pinpoint the true cause of those "correlation failed" errors, but cannot be sure. We do have data protection in place that prevents issues with load balancing and multiple instances. We're almost certain it's not related to HTTP vs HTTPS. But foremost, it looks like this error is more frequent lately, though we don't see what change could have triggered this.
One thing we realized, and we're not sure of the impact, is that the Google authentication is configured without an explicit SignInScheme:
services.AddAuthentication()
.AddGoogle(options =>
{
var section = Configuration.GetSection("ExternalLogin:Google");
options.ClientId = section.GetValue<string>("ClientId");
options.ClientSecret = section.GetValue<string>("ClientSecret");
});
Documentation about IS4 seems to indicate we should have set this in the first place:
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
On the other hand, articles like this one say that this scheme gets replaced by ASP.NET Identity.
Because ASP.NET Identity also changes the default authentication scheme, any instances of IdentityServerConstants.DefaultCookieAuthenticationScheme and IdentityServerConstants.ExternalCookieAuthenticationScheme, should be changed to IdentityConstants.Application and IdentityConstants.ExternalScheme respectively.
This just adds to our overall confusion, and we're not sure if it means changes to the external login callback as well.
Can we add that simple SignInScheme line to the Google options without impacting other users which still can connect with Google Sign In without any issue? Does it have a chance to fix the correlation errors we see? Otherwise, where should we look?