CloseOnAuthenticationExpiration.
Official definition - Authenticated connections whose token sets the ExpiresUtc value will be closed and allowed to reconnect when the token expires.
It was introduced in .Net core 6. What is the equivalent of this in .Net core 3 or 5? If not what are the other options to achieve this?
I want to make sure whenever token expires it is disconnected and only upon fresh token receipt it gets connected
Related
I have configured IdentityServer 3 to use external IdentityProvider which is pointing to AAD.
As of now, when I send a request to IdentityServer, I am properly redirected to the AAD for login, however, the 'state' parameter that I am sending to IdentityServer is overridden, and the value of OpenIdConnect.AuthenticationProperties is encrypted and sent to the AAD as the state in the query string.
For eg:
https://localhost:44333/idpaad/connect/authorize?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&redirect_uri=https://localhost:44394/&response_mode=query&response_type=code&scope=openid%20email&state=9b0e82c3-e623-42f1-bede-493243c103e7
Here,
https://localhost:44333/idpaad/connect/authorize -> IdentityServer endpoint
state=9b0e82c3-e623-42f1-bede-493243c103e7 -> client generated GUID sent as querystring.
when I see in the "RedirectToIdentityProvider" middleware in the StartUp.cs of IdentityServer OpenIdConnectAuthenticationNotifications, the value of state is updated to
OpenIdConnect.AuthenticationProperties=(protected values) instead of the GUID and the same is also returned as a query string back to the Redirect URI.
enter image description here
Is there a way to send the original state and not override it by IdentityServer3?
While using wsFederation, I am not getting this issue and the same is forwarded directly to the IdP.
Any help is deeply appreciated.
Most of the time it's advisable for an Azure Active Directory integrated application to maintain an application state when sending request to Azure AD for login. And the recommended way to achieve this is to use the ‘state’ parameter as defined in the OpenID Connect standards.
If you check this document form OpenID, you will find that primary reason for using the state parameter is to mitigate CSRF attacks.
RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.
The ‘state’ parameter is used for both preventing cross-site request forgery attacks and to maintain user’s state before authentication request occurs.
In an ASP.NET or ASP.NET CORE web application using OpenID Connect OWIN middleware, the ‘state’ parameter is maintained automatically by the middleware when sending out an authentication request, this is the only reason you are seeing the state parameter getting overridden in your case.
But if you want you can add custom data in your state parameter. Use the following code in OpenIdConnectNotifications’s RedirectToIdentityProvider event to inject custom data into the ‘state’ parameter.
var stateQueryString = notification.ProtocolMessage.State.Split('=');
var protectedState = stateQueryString[1];
var state = notification.Options.StateDataFormat.Unprotect(protectedState);
state.Dictionary.Add("MyData","123");
notification.ProtocolMessage.State = stateQueryString[0] + "=" + notification.Options.StateDataFormat.Protect(state);
Check this document and Microsoft identity platform and OpenID Connect protocol for detailed information.
My .NET Core API calls a downstream API which is secured by JWT, obtained by client_credentials OAuth grant-type authentication. That JWT is only valid for one hour and needs to be refreshed. The downstream API is exposed internally in a singleton service and the service clients should not care about the token refresh.
A naïve implementation (which I currently have) is, that the service checks if the current JWT is valid and if not, refreshes the JWT with the given credentials. That JWT is then cached for 3600 (or a little bite before) seconds and the same thing happens again.
This works well for a low "traffic" situations where there will be only one service call triggering this refresh. However, on high "traffic" scenarios this creates a bottleneck, where multiple requests will wait for that authentication to complete (or worse if I would allow this service to be used stateless and in parallel, that the JWT refresh is done multiple times).
I played around with a Background Service which refreshes the token on start-up and then on each interval (minus the grace time) and only exposes the actual token to the downstream API service. However this seems overly complicated which boils down to the actual question:
What are best practices for refreshing time-bound downstream API keys?
Are there any out of the box solutions in the .NET Core world for this? I've found Microsoft.Identity.Web but it only works around Azure (which is not possible in my case).
Use IdentityModel.AspNetCore
services.AddAccessTokenManagement(options =>
{
options.Client.Clients.Add("identityserver", new ClientCredentialsTokenRequest
{
Address = "https://demo.identityserver.io/connect/token",
ClientId = "m2m.short",
ClientSecret = "secret",
Scope = "api" // optional
});
});
services.AddHttpClient<MyClient>(client =>
{
client.BaseAddress = new Uri("https://demo.identityserver.io/api/");
})
.AddClientAccessTokenHandler();
DEFAULT PROJECT IN VS 2017
I have created a new Asp.net Core web application in vs 2017 community and published it on a FTP hosting, but when I submit a form (login or user creation) I get this error:
Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery[7]
An exception was thrown while deserializing the token. System.InvalidOperationException: The antiforgery token could not be
decrypted. ---> System.Security.Cryptography.CryptographicException:
The key {...} was not found in the key ring.
What do I need to do to make it work? thanks.
If your IIS Application Pool is set to use ApplicationPoolIdentity, then you need to make sure "Load User Profile" is set to "True" for the IIS Application Pool.
See: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/default-settings?view=aspnetcore-2.1
If the user profile is available, keys are persisted to the %LOCALAPPDATA%\ASP.NET\DataProtection-Keys folder. If the operating
system is Windows, the keys are encrypted at rest using DPAPI.
Likely your issue is that you have disabled disable the user profile in IIS
, up date that and the error like
[WRN] Error unprotecting the session cookie.
System.Security.Cryptography.CryptographicException: The key {e47d051f-d492-4df7-8781-31d884833ec6} was not found in the key ring.
and Antiforgery
[ERR] An exception was thrown while deserializing the token.
Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery token could not be decrypted.
---> System.Security.Cryptography.CryptographicException: The key {e47d051f-d492-4df7-8781-31d884833ec6} was not found in the key ring.
Will most likely magically go away.
If your hosting environment is using more than one instance for the application this may be the cause of the problem.
The simplest way to solve this is to scale down to one instance and make maximum number of instances 1.
This is for the side of identity or login API.
As your application is making login to an instance.
And checking the token with another instance.
I've successfully created a new Application Group with a Server Application as well as a Web API and the OpenID Connect protocol is working w/out any issues until I try and make a call to UserInfo. The Relying Party identifier is the same GUID as Client ID of the Server Application (per the examples I have read online). I get the error below when trying to call UserInfo:
WWW-Authenticate: Bearer error="invalid_token", error_description="MSIS9921: Received invalid UserInfo request. Audience 'microsoft:identityserver:21660d0d-93e8-45db-b770-45db974d432d' in the access token is not same as the identifier of the UserInfo relying party trust 'urn:microsoft:userinfo'."
Any help would be greatly appreciated.
I also recently got this error using ADFS with the ASP.NET Core OpenIDConnect providers. In my case, disabling the UserInfo request altogether resolved the issue:
var openIdOptions = new OpenIdConnectOptions
{
...
GetClaimsFromUserInfoEndpoint = false
};
After doing this, I still had the claims that I needed for my app - email, SID, name, etc. I'm sure there are scenarios where this would not work, but it's good to know you might not need /userinfo at all. I would still be interested in knowing why the token returned from ADFS can't be used to call /userinfo, and how to fix it in ASP.NET OpenIDConnect providers.
Just set the resource accordingly:
options.Resource = "urn:microsoft:userinfo";
We are currently using ETW to generate all application traces from our web tiers (ASP.NET MVC + WebApi). We want to extend our tracing to automatically record incoming HTTP requests, and outgoing HTTP requests (preferably without having to instrument all our API/MVC code).
Hence, was looking at built-in ETW providers either in IIS or in ASP.NET that I could leverage. Looked at the following ETW providers, and tried to collect traces using PerfView:
Microsoft-Windows-HttpEvent {7B6BC78C-898B-4170-BBF8-1A469EA43FC5}
Microsoft-Windows-HttpLog {C42A2738-2333-40A5-A32F-6ACC36449DCC}
Microsoft-Windows-HttpService {DD5EF90A-6398-47A4-AD34-4DCECDEF795F}
Microsoft-Windows-Runtime-Web-Http {41877CB4-11FC-4188-B590-712C143C881D}
Microsoft-Windows-Runtime-WebAPI {6BD96334-DC49-441A-B9C4-41425BA628D8}
ASP.NET Events {AFF081FE-0247-4275-9C4E-021F3DC1DA35}
Microsoft-Windows-IIS-APPHOSTSVC {CAC10856-9223-48FE-96BA-2A772274FB53}
Microsoft-Windows-IIS-Logging {7E8AD27F-B271-4EA2-A783-A47BDE29143B}
Microsoft-Windows-IIS-W3SVC {05448E22-93DE-4A7A-BBA5-92E27486A8BE}
I'm able to capture events from other processes (including .NET + Kernel, and our own custom traces), but nothing from the above providers.
What am I missing? How do I enable the built-in ASP.NET/IIS ETW providers? Are there other providers/events that would give me the ability to inspect the incoming & outgoing HTTP requests?
Platform: Running Windows 8.1/Windows Server 2012 R2 + ASP.NET 4.5 + IIS 8.5
Making a research myself and i'm able to collect incoming HTTP requests to my IIS Express service with ctrl.guid file containing only one provider (make sure you set 0xffff and 0x5 as flags):
{DD5EF90A-6398-47A4-AD34-4DCECDEF795F} 0xffffffff 5 Microsoft-Windows-HttpService
Deliver event has URL and application pool that will handle request "Clr4IntegratedAppPool{guid}" in my case.
Here are the list of events of ASP.NET, IIS and HTTP events I used.
aff081fe-0247-4275-9c4e-021f3dc1da35
ee799f41-cfa5-550b-bf2c-344747c1c668
de4649c9-15e8-4fea-9d85-1cdda520c334
de4649c9-15e8-4fea-9d85-1cdda520c334
aff081fe-0247-4275-9c4e-021f3dc1da35
06b94d9a-b15e-456e-a4ef-37c984a2cb4b
d55d3bc9-cba9-44df-827e-132d3a4596c2
a1c2040e-8840-4c31-ba11-9871031a19ea
3a2a4e84-4c21-4981-ae10-3fda0d9b0f83
23108b68-1b7e-43fa-94fb-ec3066805744
7b6bc78c-898b-4170-bbf8-1a469ea43fc5
dd5ef90a-6398-47a4-ad34-4dcecdef795f
cac10856-9223-48fe-96ba-2a772274fb53
ab29f35c-8531-42ff-810d-b8552d23bc92
bbb924b8-f415-4f57-aa45-1007f704c9b1
da9a85bb-563d-40fb-a164-8e982ea6844b
05448e22-93de-4a7a-bba5-92e27486a8be
90303b54-419d-4081-a683-6dbcb532f261
23108b68-1b7e-43fa-94fb-ec3066805744
670080d9-742a-4187-8d16-41143d1290bd
de4649c9-15e8-4fea-9d85-1cdda520c334
Edit:-
Here is a post on How I used these additional providers troubleshoot the request and response messages from IIS to external authentication providers.
View the http redirect and response message from an external authentication provider using ETW