I have an application system that developed based on IdentityServer4 and .NET Core 2.0. Just recently I noticed that log into the server will timeout in 30 minutes regardless of user activity. Client applications cannot launch other SSO enabled applications after the 30 minutes boundary. After 30 minutes, launching any new app will force user login. I looked at the cookies that might affect the SSO functionality, there are three: AspNetCore.Identity.Application, Identity.External and idsrv.session. But they are all browser session cookies. I don’t see how they would timeout. Anyone knows what’s going on?
My related settings:
Absolute Refresh Token Lifetime: 2592000
Access Token Lifetime: 3600
Authorization lifetime 300
Identity Token Lifetime: 300
mode777 is right. This issue is not related to IdentityServer4 nor OpenID Connect. It's related to the AspNetCore.Identity. I find this link very helpful and solved my timeout issue by adding a line like this:
services.Configure<SecurityStampValidatorOptions>(options => options.ValidationInterval = TimeSpan.FromHours(24));
So, what happened is this: After the 30 mins default interval, a request to the server will go through the user security stamp check. For some unknown reason, the logic that checks my user security stamp think the stamp is invalid and hence calls SignInManager's SignOutAsync, which kills everything. What I still don't understand is that my user security stamp is never changed! It shouldn't cause the invalidation. For now, I will let my application works with a much longer check interval, and will keep an eye on the security stamp.
First of all this is not a Identity Server 4 or OpenID Connect related issue. This concerns the local login probably goverened by Asp.Net Identity which is probably Cookie based (It all depends on your configuration - Startup.cs would be nice).
You can configure the session timeout for Asp.Net Identity which is described here: ASP.NET Identity Session Timeout
Have you tried that?
Digging though source code I found that the cause is missing SecurityStamp claim (default name: AspNet.Identity.SecurityStamp) in auth cookie (.AspNetCore.Identity.Application). After 30 minutes (default value for options.ValidationInterval) security stamp is validated against stamp in the store. If it's missing in cookie - validation fails immediately.
So the solution would be to put security stamp in the cookie.
In my case problem was caused because I was using wrong Sign-In method: HttpContext.SignInAsync instead of build-in Asp.Net Identity SignInManager.SignInAsync which is preferable to use in most cases. SignInManager.SignInAsync puts that claim in the cookie.
Related
I am using identity server 4 for my react application with using of redux-oidc library
, I need to renewal token every 5 min as silent.
Issue:
when execute Silent renewal getting timeout issues.
So, I implemented silent renew code like below
my configuration
My silent renewal.js file
[token renewal times i set in identity] (https://i.stack.imgur.com/FTwVH.png)
identity level also silent Renew URL added.
I added my configuration like this. its working as inconsistency sometimes it is working fine but randomly it is getting issues.
how can i resolve this?
I am using watson assistant with flask framework. Once the session expires i get the following error
ApiException(response.status_code, error_message, http_response=response)
ibm_cloud_sdk_core.api_exception.ApiException: Error: NotFound: session id ba62bf14-87e-4c7b071b591e for agent instance 0e5c653c-9-b4e0-5a597c3e541e, Code: 404 , X-global-transaction-id: ffea409d54977b49
127.0.0.1 - - [03/Jul/2019 11:27:47] "GET / HTTP/1.1" 200
Refreshing the page does not create a new session
How to create a new session on this exception, so that I need not restart the local server ?
You mention a 5 minute session timeout.
Watson Plus trial has this set for just testing, and is not intended to be production level. It cannot be changed.
Standard version and lite can use session but both were originally stateless. You should use the V1 API for these. You will have to manage the state, but you will no longer have a time out.
If you are using the paid version of Watson Plus, or premium you can change the time out within the assistant settings.
You need to provide code, as any response will be blind and based on guesswork on what errors you have made, and there are many. But based on the fact that you failed to provide code, and still raised the question expecting someone to tell you what you did wrong then let's go with a rookie error.
I think you are creating the session as a global in your flask app, and maybe saving it it the app object. You probably have a route for the dialog, which makes use of the session. The code in this route, needs to catch the error, or test if the session is still valid, and recreate it. If you are catching the error, and trying to recreate the session, then you may have fallen foul of Python's global variable restrictions. Essentially if in a function you have a variable as the right side of an assignment, then its scope will be limited to the function.
Refreshing the web page, will not force the flask app to re-create the session. As you probably have that logic outside of any routes.
We recently started working on a solution where we want access to user's resources as part of server-to-server calls and authenticated the users with Microsoft work accounts with Azure AD's OAuth 2.0 approach.
We implemented OAuth 2.0 authentication using Microsoft.IdentityModel.Clients.ActiveDirectory Version 2.24 and released in market. About 2 days back, we started getting following errors for some users
"The refresh token has expired because of inactivity for 14 days"
After investigating, We found the following:
By Default, Azure AD refresh tokens are valid for about 14 days.
Access token can only be refreshed for a maximum period of 90 days (given that we "refresh" our refresh token)
90 days after the initial issuance of the access and refresh tokens, the end user will have to sign themselves in again
Currently, these settings are not configurable in Azure AD
In order to solve the issue, we were trying to move to the recently released Microsoft.IdentityModel.Clients.ActiveDirectory Version 3.10. While upgrading from library version 2.24 to 3.10, I was not able to use the RefreshToken that I persisted after serialized using version 2.x, error occurred while doing deserializing with version 3.x (I noticed that the class TokenCache has undergone some changes).
So, I have following questions:
Since, the refresh token in question was getting used to acquire access tokens regularly during the 14 days period, we would like to undertand “What is the definition of "inactivity" for a refresh token?” If it only contains getting access tokens, why did the refresh token expired at the first place? Please note that the call that I was using to get the access token was AuthenticationContext.AcquireTokenByRefreshToken. Could that be the issue? (Link to ADAL 3 didn’t return refresh tokens for ~5 months…
How can I use the persisted serialized 2.x token cache with the library version 3.x?
Given that we move to the version 3.x and use the calls AuthenticationContext.AcquireTokenSilentAsync to get the access tokens on a regular basis, I won't run into the above issue again for a period of 90 days. Can you please confirm the approach I am taking.
Can we get the refresh token for more than 90 days period to avoid asking the user to re-authenticate every quarter?
Do the refresh Token gets invalidated if user changes the password?
It is really late to answer this, by now you may have figured it out the solution. If so, please post your answer.
I had same problem when we shifted to AD 3.10 yesterday and I was missing a call to below line and it worked
var authenticationResult = await authContext.AcquireTokenByAuthorizationCodeAsync(httpCookie.Value, uri, credential);
YOu have to give a call to this before you call authContext.AcquireTokenSilentAsync( ...) Please try at your end .
I am using PF 5.2.0 to setup an IdP and also multiple SP's. My question is about the single Logout senario.
if session has been established by SP1 and SP2 with my IdP then on IdP initiated logout it works fine by issuing samlp:LogoutRequest to both the SP's. Am facing an issue if one of SP's is down after establishing an session with the IdP then SLO does not complete, meaning if SP1 is down then samlp:LogoutRequest is not send to SP2 assuming the first logout request is sent to SP1 which is down.
I am using POST binding, but I believe this will be the same result for redirect as well
awaiting in anticipation for your comments..
-Vj
Vj -
This is "by design" behavior with front-channel SAML 2.0 SLO and really doesn't have anything specific to do with PingFederate. It's also one of the reasons you don't see many Enterprises using SLO.
One of the drawbacks of SAML2.0 SLO is that it can be very fragile. As you have noticed, if any of the SPs fail to return a response to the IDP, the entire transaction is stopped since the IDP is waiting to resume the transaction. Unfortunately, this is just how front-channel SAML 2.0 SLO works. I believe with SOAP-based SLO, since the browser is never involved, it does not have the same limitation. However, this requires the SP to keep the user's state in a database that can be removed when it receives the SLO request w/out the need to also get access to the user's browser cookies to remove the session (since the browser will never visit the SP in this scenario).
HTH
--Ian
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.