Below is my code to popup and login through MSAL.
var app = PublicClientApplicationBuilder.Create(msal.ClientId)
.WithDefaultRedirectUri()
.WithTenantId(msal.TenantId)
.Build();
var result = await app.AcquireTokenInteractive(msal.Scopes).ExecuteAsync();
Code above works when it's running on my local machine.
And below is my settings in Azure AD. Its working when I set it to localhost:5000
But when I set the localhost to 'myWebAppUrl' which is hosted on Azure Virtual Machine. MSAL won't popup. And it will just return "The operation was cancelled". Anything I missed here?
Please check the below points.
In azure ad,the reply URL must begin with the scheme https, unless using localhost. ex:http://localhost:5000
Else you can use something like https://yourappurl and don’t forget to Grant admin consent
Under Permissions for the scopes you have in azure ad.
Please check Redirect URI restrictions
Apps that use system browsers: http://localhost
Apps that use embedded
browsers:https://login.microsoftonline.com/common/oauth2/nativeclient
For Node.js, you can use msal://redirect
Please check Add a redirect URI section and Client application configuration (MSAL) | Microsoft Docs
And check if you can use confidential client to your app
.
Some authentication libraries like MSAL.NET use a default value of
urn:ietf:wg:oauth:2.0:oob when no other redirect URI is specified,
which is not recommended. This default will be updated as a breaking
change in the next major release.
Other references
Instantiate a public client app (MSAL.NET) - Microsoft identity platform | Microsoft Docs
Initialize MSAL.NET client applications - Microsoft identity platform | Microsoft Docs
Related
Trying to implement windows authentication on my published asp.net core 2.2 application.
Hosting server is Windows server 2016 (IIS).
I would like to use the active directory logged in user account to authenticate the user on my application.
I'm getting the user details by these methods:
User.Identity.Name; //return null in local host, worked when IIS
System.Security.Principal.WindowsIdentity.GetCurrent() // local host
I keep getting in the browser, the Sign in dialog box (although I would like to get rid of it, even when entering credentials - <username> + password - it doesn't authenticated).
I would like to get rid of it
Stop getting error 401 - unauthorized
I've configured what ever I was advised - both IIS and browser, but still - keep getting it:
Browser:
Browser security - Entered the host IP address to the trusted sites
IIS:
Set Authentication => enable Windows Authentication to true.
Through web.config - set "forwardWindowsAuthToken" to "true".
Site Configuration:
In the IIS site configuration (applicationHost) - system.webserver -> Security -> Authentication -> windows authentication -> "UseKernelmode" = "true"
ApplicationPool:
.NET CLR Vesrion = "No Managed Code"
Managed Pipeline Mode = " Integrated"
event tried to change in the "advanced settings" the Identity from "ApplicationPoolIdentity" to "NetworkService"
NTFS permissions:
Set basic and defaults Permissions to the account<Server host Name>\IIS_IUSRS on the server published code directory: Read & Execute, List folder contents, Read.
Maybe the problem is here - because the IIS_IUSRS account is defined in the server and not in the domain ?
You can try this method to solve the problem:
Open iis and in Windows Authentication, Right-Click to set the Providers, set the NTLM to be FIRST.
Check that under Advanced Settings... the Extended Protection is Accept and Enable Kernel-mode authentication is checked.
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 trying to secure the Azure functions using Azure Active Directory following the note.
When the link https://xxxfunction1.azurewebsites.net/api/function1 is entered, the browser redirects to AAD:
https://login.microsoftonline.com/[tenent]/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fxxxfunction1.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=[client_id]&scope=openid+profile+email&response_mode=form_post&nonce=[nonce]state=redir%3D%252Fapi%252Ffunction1
and the error returns:
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application
The platform configurations in the AAD client:
The Authentication & Authorization in Azure function xxxfuntion1 is configured to AzureAD client xxxfunction1app:
The same error with Advanced mode:
Any idea why it says the error on the reply URL please?
Your error is very simple. Your redirect_uri is decoded as: https://xxxfunction1.azurewebsites.net/.auth/login/aad/callback, but you configure the redirect_uri in the AAD client as:https://xxxfunction1.azurewebsites.net/.auth/login/aad/callcack, so the response url does not match error, you only need to change callcack to callback.
Make sure that the URL matches exactly and double-check that the Application ID and tenant ID are matching. It might be trying to resolve to a different application or tenant.
The identifier URI should be: https://xxxfunction1.azurewebsites.net
Please go to Azure Portal > Azure Active Directory > App Registration > All Applications > Search with the App ID 6419ae-xxxx-xxxx-xxxx > Under Authentication blade of the application update the Redirect URI to ttps://xxxfunction1.azurewebsites.net/api/function1
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"
}
While debugging, we observe following behavior:
1) When trying to get encryption key from server then error on both (iOS or Android) platform
response [https://xxxx.xxxx.com:443/worklight/apps/services/random]
success: Exception thrown by application class
'com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity():685'
SESN0008E: A user authenticated as anonymous has
attempted to access a session owned by user:NewRealm/CN=test
user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
2) When trying to read a stored value error on android is [Logcat]
Android Message: Uncaught 9 at
file:///data/data/com.xxxx.xxxxapp/files/www/default/wlclient/js/encryptedcache.js:63
Where try to call WL.EncryptedCache.read
Worklight version used is 5.0.5 Consumer Edition (with Oracle 11i) on
Windows 2008 R2
WebSphere Liberty profile
Worklight server is sitting behind IBM Datapower XI52. All SSL calls to the server are going via DP.
Authenticator - WebSphereFormBasedAuthenticator & LoginModule - WASLTPAModule
The following is not really an answer, since I'm not familiar with authentication (LTPA, FormBasedAuth, Data Power, etc.)... just a couple of comments that could help you debug/isolate the issue.
Looks like a problem with authentication:
A user authenticated as anonymous has attempted to access a session
owned by user:NewRealm/CN=test user,OU=Temporary
Users,OU=Acc,DC=xxxx,DC=com.
Not with the Encrypted Offline Cache (EOC).
EOC will try to get a random token calling the following function:
WL.EncryptedCache.secureRandom(function (data) {
console.log(data);
});
It should output something like this:
response [/apps/services/random] success: 9053bdcfd902aac3dfb59a9874c9cf55223b7d17
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view the functions source code typing the following in a JS console:
WL.EncryptedCache.secureRandom
If you're using Google Chrome developer tools there's a checkbox for Log XMLHttpRequests when you click on the gear icon > General > Console.
You can also try to request the URL directly. Assuming the host is localhost, port is 10080 and project name is wlproj:
http://localhost:10080/wlproj/apps/services/random
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view HTTP traffic with Wireshark or Charles Proxy.
I imagine this will fix the EOC issue for you, if you don't mind generating the random token locally (less security, AFAIK):
WL.EncryptedCache.secureRandom = function(callback){callback(Math.random()+"")}
For example:
Notice it never goes to the server, everything is done locally.
A user authenticated as anonymous has attempted to access a session owned by user:NewRealm/CN=test user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
This usually means that there is a conflict with the session sent by the user (the session cookie) belongs to a user (in this case), but the LTPA token sent as a cookie was not sent or was not valid. There could be a few causes of this. This best way is to do a trace between datapower and the worklight server to make sure an LTPA token is even being sent to the worklight server. If it is, verify all of the LTPA requirements are met (synchronized time, same private key on both machines).