I am trying to get things to work in our Test environment, which mimics Production. In our Test/Prod environment we have 2 servers that are load balanced.
Initially, everything works. I can do IdP/SP initiated SSO/SLO without issue. The problem is, that non-SAML accounts can’t login after someone has logge din via SAML. Before that, they can login fine. If I reset Application Pools on the web servers, it starts working again.
This caused me to look back at the documentation, specifically around Sessions.
Is configuring the SamlIdentifiers database in section 5.5.2 DatabaseIDCache required in this case? Currently I have not done anything in regard to IDCache configuration.
I have the SSOSessions table setup (5.6.2 DatabaseSSOSessionStore), but my configuration for it was using InProc. I followed the documentation to change it to Custom, but this didn’t change anything. Is my issue because I don’t have 5.5.2 configured along with 5.6.2? Or is there potentially something else causing me issues?
The IDCache won’t be causing any issues. It’s only required if your site is the service provider. It’s used to detect potential assertion replay attacks. In a web farm, ideally a single ID cache should be shared by all servers. If you don’t then each server will have its own ID cache so you could miss a potential replay attack. None of this affects normal logins.
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you’re using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you’re using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you’re using non-sticky sessions and don’t have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can’t login?
Is the SAML user still logged in even though they apparently logged out?
[quote][/quote]
The IDCache won't be causing any issues. It's only required if your site is the service provider. It's used to detect potential assertion replay attacks. In a web farm, ideally a single ID cache should be shared by all servers. If you don't then each server will have its own ID cache so you could miss a potential replay attack. None of this affects normal logins.
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Non-SAML Account: We have clients that are going to use SAML to authenticate with our system. We have other clients that use username/passwords that we manage to login to our system. It is the 'other clients' that I was referring to for this.
SAML user still logged in: If I initiate SLO from the SP or the IdP, the user is properly logged out.
Sticky Sessions: I will have to double check, but I believe we are using Sticky Sessions on the load balancer.
ASPNet Sessions: We are using ASPnet Identity with Forms Authentication. This utilizes session cookies and Claims management. After the 'non-SAML' account logs in, they are redirected to the main page of the application. It is here via 'Global.asax' that it checks to see that the individual is authenticated:
if (HttpContext.Current.User != null && HttpContext.Current.User.Identity.IsAuthenticated) {}
This is where the user is getting lost and so is unable to login. Normally, it gets past this point no problem, but as soon as any SAML account authenticates (whether they stay logged in or they log out), then the above process breaks.
I only added Session State settings for the SAML integration as the application complained without it. Hopefully this information will help you help point me in the right direction.
[quote][/quote]
The IDCache won't be causing any issues. It's only required if your site is the service provider. It's used to detect potential assertion replay attacks. In a web farm, ideally a single ID cache should be shared by all servers. If you don't then each server will have its own ID cache so you could miss a potential replay attack. None of this affects normal logins.
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Non-SAML Account: We have clients that are going to use SAML to authenticate with our system. We have other clients that use username/passwords that we manage to login to our system. It is the 'other clients' that I was referring to for this.
SAML user still logged in: If I initiate SLO from the SP or the IdP, the user is properly logged out.
Sticky Sessions: I will have to double check, but I believe we are using Sticky Sessions on the load balancer.
ASPNet Sessions: We are using ASPnet Identity with Forms Authentication. This utilizes session cookies and Claims management. After the 'non-SAML' account logs in, they are redirected to the main page of the application. It is here via 'Global.asax' that it checks to see that the individual is authenticated:
if (HttpContext.Current.User != null && HttpContext.Current.User.Identity.IsAuthenticated) {}
This is where the user is getting lost and so is unable to login. Normally, it gets past this point no problem, but as soon as any SAML account authenticates (whether they stay logged in or they log out), then the above process breaks.
I only added Session State settings for the SAML integration as the application complained without it. Hopefully this information will help you help point me in the right direction.[/quote]
I had confirmed otherwise, that sessions are not sticky. So it appears from your feedback I would have to use DatabaseSSOSessionStore?
Eitherway, I do not believe having that properly set up fixes the issue that I'm seeing.
[quote][/quote]
The IDCache won't be causing any issues. It's only required if your site is the service provider. It's used to detect potential assertion replay attacks. In a web farm, ideally a single ID cache should be shared by all servers. If you don't then each server will have its own ID cache so you could miss a potential replay attack. None of this affects normal logins.
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Are you using sticky sessions?
Is your application using ASP.NET sessions? If so, which mode?
If you're using sticky sessions and you have InProc mode ASP.NET sessions configured, a central (eg database) SSO session store is not required as the default SSO session store that uses the ASP.NET session will suffice.
If you're using non-sticky sessions and you have StateServer or SQLServer mode ASP.NET sessions configured then, once again, the default SSO session store will suffice.
However, if you're using non-sticky sessions and don't have ASP.NET sessions enabled, you will need to use a central SSO session store such as the DatabaseSSOSessionStore.
Could you describe what you mean by non-SAML accounts can't login?
Is the SAML user still logged in even though they apparently logged out?
Non-SAML Account: We have clients that are going to use SAML to authenticate with our system. We have other clients that use username/passwords that we manage to login to our system. It is the 'other clients' that I was referring to for this.
SAML user still logged in: If I initiate SLO from the SP or the IdP, the user is properly logged out.
Sticky Sessions: I will have to double check, but I believe we are using Sticky Sessions on the load balancer.
ASPNet Sessions: We are using ASPnet Identity with Forms Authentication. This utilizes session cookies and Claims management. After the 'non-SAML' account logs in, they are redirected to the main page of the application. It is here via 'Global.asax' that it checks to see that the individual is authenticated:
if (HttpContext.Current.User != null && HttpContext.Current.User.Identity.IsAuthenticated) {}
This is where the user is getting lost and so is unable to login. Normally, it gets past this point no problem, but as soon as any SAML account authenticates (whether they stay logged in or they log out), then the above process breaks.
I only added Session State settings for the SAML integration as the application complained without it. Hopefully this information will help you help point me in the right direction.[/quote]
I had confirmed otherwise, that sessions are not sticky. So it appears from your feedback I would have to use DatabaseSSOSessionStore?
Eitherway, I do not believe having that properly set up fixes the issue that I'm seeing.[/quote]
I've confirmed that changing the SessionState from InProc to Custom (like how it is configured in the example project) does not work, it actually makes the problem worse. SAML still works, but now you can't login with a normal (non-SAML) account regardless if you reset IIS or reset the Application Pools.
This leads me to believe the issue might be with the combination of SessionState and ASPNet Identity. I may have to go at this from another angle unless you guys have any thoughts/recommendations. I'm not finding any scenarios online where people are using a Custom Provider for SessionState along with ASPNet Identity 2.0.
If you’re using ASP.NET sessions then you can use the default SAML SSO session store. You don’t need to use the DatabaseSSOSessionStore.
As you say, the symptoms you’re seeing don’t match with an SSO session store issue.
Could you elaborate on what you mean by the user is getting lost?
Does the code in Global.asax indicate the user is already authenticated?
If you close all instances of the browser and try again, does the same issue occur?
[quote][/quote]
If you're using ASP.NET sessions then you can use the default SAML SSO session store. You don't need to use the DatabaseSSOSessionStore.
As you say, the symptoms you're seeing don't match with an SSO session store issue.
Could you elaborate on what you mean by the user is getting lost?
Does the code in Global.asax indicate the user is already authenticated?
If you close all instances of the browser and try again, does the same issue occur?
As you say, the symptoms you're seeing don't match with an SSO session store issue.
Could you elaborate on what you mean by the user is getting lost?
Does the code in Global.asax indicate the user is already authenticated?
If you close all instances of the browser and try again, does the same issue occur?
As I understand it, ASPNet Identity 2.0 uses Cookie Claims, i don't believe it uses a Session Store. That is why I get errors if I do not have one enabled in web.config.
In Global.asax, I have a check to see if the user is already authenticated. Normally this works great after login. This is the spot where it is not finding the user being authenticated. By the time the user gets to this page, they are no longer signed in, even though on the Login page, login comes through fine.
As to closing browser, etc. Yes, I can close all browsers, try a different browser, once I've logged in using SAML, I can no longer log into the system with a non-SAML account. If I'm using InProc as the SessionState setting, I can reset IIS or recycle the application pool and then I can login with non-SAML accounts again.
So, just to confirm my understanding, the follow is occurring.
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they’re not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn’t help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It’s hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn’t appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
[quote][/quote]
So, just to confirm my understanding, the follow is occurring.
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
You are correct.
To log them in and out I use the same cookie construction and deconstruction process for the claims based authentication of the non-SAML user. The log out of course happening after initiating the SLO process with the IdP.
To add more confirmation around closing/refreshing browser....After step 1 above, if a coworker tries to do step 2, it fails, whereas prior to step 1, step 2 would succeed.
I am at a loss.
[quote][/quote]
So, just to confirm my understanding, the follow is occurring.
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
You are correct.
To log them in and out I use the same cookie construction and deconstruction process for the claims based authentication of the non-SAML user. The log out of course happening after initiating the SLO process with the IdP.
To add more confirmation around closing/refreshing browser....After step 1 above, if a coworker tries to do step 2, it fails, whereas prior to step 1, step 2 would succeed.
I am at a loss.
[/quote]
What is weird with all of this... on my local machine I have no issues with the whole process and as a side note, I've tried disabling one of the two web farm servers so that we are dealing with just 1 server and that doesn't change the outcome at all.
[quote][/quote]
So, just to confirm my understanding, the follow is occurring.
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
1. A user logs in using SAML SSO. They then logout.
2. A non-SAML user logs in successfully. However, your HttpContext.Current.User.Identity.IsAuthenticated check in Global.asax shows that they're not authenticated.
3. Closing the browser, using a different browser and, presumably, a different client machine doesn't help. The only solution is to recycle IIS or the application pool.
Is my understanding correct?
It's hard to understand how the SAML SSO or SLO would cause this issue.
I can understand how a failed SLO would mean the user is still logged in within the same browser session.
However, the issue doesn't appear to be related to a browser session.
Could it be something to do with how you log the user in and out as part of SAML SSO/SLO?
You are correct.
To log them in and out I use the same cookie construction and deconstruction process for the claims based authentication of the non-SAML user. The log out of course happening after initiating the SLO process with the IdP.
To add more confirmation around closing/refreshing browser....After step 1 above, if a coworker tries to do step 2, it fails, whereas prior to step 1, step 2 would succeed.
I am at a loss.
[/quote]
What is weird with all of this... on my local machine I have no issues with the whole process and as a side note, I've tried disabling one of the two web farm servers so that we are dealing with just 1 server and that doesn't change the outcome at all.[/quote]
Alright...I've figured out a solution to my problems.
I setup a new website in IIS (same servers) and pointed them to the same website directory. I moved the saml URL binding over to the new site, and made sure it's in its own Application Pool. This allows SAML authentication to occur without problem, and the normal site never gets interferred with as it is in a different Application Pool.
I do appreciate all of your help, your questions helped me walk through the process.
Thanks for the update. I’m glad you find a solution.
Any ideas why a separate application pool is necessary?
[quote][/quote]
Yes, it's very strange.
Could you please enable SAML trace on one of the web farm servers and send the generated log file as an email attachment to support@componenrspace.com mentioning this forum post? I'd like to see SSO and SLO.
I can check that there's nothing odd in the trace but I'm not expecting to see anything.
http://www.componentspace.com/Forums/17/Enabing-SAML-Trace
The only other thing I can suggest is to use something like Fiddler or browser developer tools to capture the HTTP traffic.
You could then compare what happens when using the web farm vs your local machine, paying attention to cookies etc.
Another thing to try, if it's possible, is to hit the web farm server directly without going via the load balancer, just in case the LB is having a negative impact.
Could you please enable SAML trace on one of the web farm servers and send the generated log file as an email attachment to support@componenrspace.com mentioning this forum post? I'd like to see SSO and SLO.
I can check that there's nothing odd in the trace but I'm not expecting to see anything.
http://www.componentspace.com/Forums/17/Enabing-SAML-Trace
The only other thing I can suggest is to use something like Fiddler or browser developer tools to capture the HTTP traffic.
You could then compare what happens when using the web farm vs your local machine, paying attention to cookies etc.
Another thing to try, if it's possible, is to hit the web farm server directly without going via the load balancer, just in case the LB is having a negative impact.
I will try to get to that within the next day or two.
I realized why it was working locally, because I had my SAML endpoint under a separate website with Application Pool (like I now have on my Test servers). Either way, I will try to get you those logs when I can.
Thanks.