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
Related
It seems keeping all the browsers happy is a challenging task, what with all the security they are adding and the complexities of certificates.
I have a SPA (Vuejs) which is using oidc-client.js to implement OIDC, communicating with an Identity Server (Identity Server 4).
First thing to note is that everything works if I run both client and server on localhost.
It is when I deploy the Identity Server to a Staging Server inside our network that things go awry.
So, the hostname of the Idp now differs to that of the SPA (which would be normal in production).
After much work, I've got everything working except IE11 (yep IE).
I had to do several things to get me there such as:
solve the samesite cookie issue of Chrome
create self-signed certificates and install the root certificate in the Trusted Certificates
add Babel config code and Core.js at the client, to enable IE to not throw errors when promises come into play
So, it's been a long road, yet still, I have to deal with this (see animation):
I just can't quite figure out why IE is doing that.
It is not possible to use the dev tools to see any info.
The logs at the server do not contain any information that seems relevant.
Has anyone else seen these "Browser symptoms" in IE.
Happy to provide more information (code, logs etc.) if people think that will help. Just didn't want to dump all that in the initial question, as many people don't like that.
Here are a couple of Fiddler screenshots. The first is from Chrome:
The second on is for IE11.
For some reason, the Silent Refresh is being invoked over and over again with IE11.
I think I can see what is happening, but not sure how to fix it.
There appears to be 2 calls to the Authorize endpoint which fail, conspicuously missing the .AspNetCore.Antiforgery cookie. This results in 2 invocations of silent-refresh.html.
Then, for some reason there is some king of GET request to the base url of the Idp and immediately following on the heels of that request is a request to the Authorize endpoint which does have the .AspNetCore.Antiforgery cookie.
The ship is set straight until the next call to the Authorize endpoint which is the beginning of the next cycle.
However, with Chrome, after the user is logged in, the next call to the Authorize endpoint does contain the cookie.
So, I guess it is the missing cookie which is the issue.
Perhaps this has something to do with the code which I used from this post to solve the Chrome samesite cookie issue?
Cheers
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.
I am developing an alexa skill that requires account linking. The Account linking succeeds first 2 times(enable skill-disable it- and again re-enable the skill). Account linking fails only when I re-enable immediately after disabling the skill. I use Code grant auth type. The data (in the query string state/code/etc) are successfully redirected back to amazon's redirect/return url value. But Amazon ends the account linking process with a message stating that the account linking process failed at this time. Could anyone has any idea? Your help is much appreciated.
Answer: Finally I figured out the issue. The authorization server runs in 2 machines (instanes). The authorization server uses concurrent dictionary to store the access tokens. The concurrent dictionary uses local memory (in proc memory). During the authentication, the Amazon connected to one of the Auth server; that Auth server stores the access code in it's memory store. When the Amazon tries to get the access code from my authorization server using the code value that was returned to the Amazom previously, the second authorization server got hit. The second auth server does not have the access token for the amazon provided code, hence it invalidates the request. The solution is to use the shared store (out of process memory like REDIS cache) to store the access codes. So that both authorization servers can serve the request by referring the same store.
We currently have ADFS 2.0 with hotfix 2 rollup installed and working properly as an identity provider for several external relying parties using SAML authentication. This week we attempted to add a new relying party, however, when a client presents the authentication request from the new party, ADFS simply returns an error page with a reference number and does not prompt the client for credentials.
I checked the server ADFS 2.0 event log for the reference number, but it is not present (searching the correlation id column). I enabled the ADFS trace log, re-executed the authentication attempt and this message was presented:
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
As the message indicates that the request is not well formed, I went ahead and ran the request through xmlsectool and validated it against the SAML protocol XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) and it came back clean:
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
So, I'm thinking that ADFS isn't playing full compliance with the SAML specification. To verify, I manually examined the submitted AuthnRequest, and discovered that our vendor is making use of the 'Extensions' element to embed their custom properties (which is valid, according to the SAML specification) (note: "ns33" below correctly namspaces "urn:oasis:names:tc:SAML:2.0:protocol" elsewhere in the request)
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
If I remove the previous element from the AuthnRequest and resubmit it to ADFS, everything goes swimmingly. And, in fact, I can leave the 'Extensions' container and simply edit out the vendor namespaced element, and ADFS succeeds.
Now, I guess I have 3 questions:
Why was the reference number not logged to the ADFS log? That really would have helped my early debugging efforts
Is it a known issue that ADFS's SAML handler cannot handle custom elements defined within the Extensions element, and if so, is there a way to add support (or at least not crash while handling it)? My vendor has offered to change the SAML AuthnRequest generated to omit that tag, but said that it 'may take some time'-- and we all know what that means...
Does anyone think that installing ADFS hotfix rollup 3 will address this situation? I didn't see anything in the doc to indicate the affirmative.
Thanks for your feedback.
When facing a MSIS7015 ADFS error, the best place to start would be enabling ADFS Tracing. Login to the ADFS server as admin and run the following command. If you have a very busy ADFS server, might be wise to do it when the server is not as busy.
C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc
In Event Viewer select “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Go to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging.
Process your ADFS login / logout steps and when finished, go to the event viewer mmc find the sub tree AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
Look for EventID 49 - incoming AuthRequest - and verify values are not being sent with CAPs value. For example, in my case, it was I was receiving the following values: IsPassive='False', ForceAuthn='False'
In my case, to address the issue, all I needed to do was create incoming claim transformer rule - for the distinct endpoints.
Once the CAPs were transformed to lower case true and false, authentication started working.
I need to stress-test a silverlight application which uses Windows authentication mode. To achieve this task I am using the StressStimulus Fiddler addin.
What I am doing is to log in and doing some stuff like search etc. I captured the HTTP messages transferred in Fiddler and replayed them using the above mentioned tool.
However, when I replay the packages I always get a 401.1 Server responses.
I tried to use different Authorization approaches (NTLM and Negotiate) but I always get the same response message.
Fiddler seems to be properly configured. In the Fiddler options menun "Reuse client connection" is checked as well as "Reuse connection to server". I even raised the KeepAliveTimeout in the registry without any success.
Does anybody have an idea whats going wrong?
You can't replay authentications such as NTLM and Negotiate. One the most important features of any challange/response authentication is that it must not be replayable. Without this feature an attacker can monitor a successful authentication and then replay the same sequence to gain access to things they aren't entitled.