After successfull authentication from IDP, How do i need to store SAML session in ccokies,
How i need to check the session stored in cookie when i open new browser?
The SAML cookie is a session cookie.
If the user closes the browser, the cookie is lost.
Perhaps if you could explain your requirements and the use case you wish to support, I can provide some suggestions.
[quote]
[/quote]
My Requirment is like,
I have 3 service providers, If I login from one of the service provider using IDP, I need to access all the three service providers,
I have a log out button as well, I need to logout from IDP as well as form Service provider level.
Once I access from IDP, I need to the SAML Session in database, and if again user the url in new browser , i need to check the session exists or not and i need to take him to default page.
What key do i need to store after getting response from IDP? where i need to store ? How i need to authenticate later?
What you describe is supported as long as the browser isn’t closed.
You would need to use a persistent cookie to support this scenario over browser invocations.
This isn’t supported currently.
Presumably it also makes sense only if the IdP and SP authentication cookies are persistent.
Please contact support@componentspace.com to see whether this support can be added.
I have a similar issue with Saml. From the USP server when i hit the IDP link and then redirect to the application. I get logged in. But when I do the same thing (even though i am already logged in) it re-logs in because the session id is not the same this time. Is there any configuration that I am missing?
The user is doing this activity in the same browser.
Do you mean the IdP prompts the user to login again even though it’s the same browser session?
If so, this is dependent on how the IdP handles authentication sessions and isn’t directly related to SAML. You might want to take a look at the authentication cookie used by the IdP and whether there’s any issue with it not being sent by the browser. The browser developer tools are useful for investigating this sort of issue.
[quote][/quote]
Do you mean the IdP prompts the user to login again even though it's the same browser session?
If so, this is dependent on how the IdP handles authentication sessions and isn't directly related to SAML. You might want to take a look at the authentication cookie used by the IdP and whether there's any issue with it not being sent by the browser. The browser developer tools are useful for investigating this sort of issue.
If so, this is dependent on how the IdP handles authentication sessions and isn't directly related to SAML. You might want to take a look at the authentication cookie used by the IdP and whether there's any issue with it not being sent by the browser. The browser developer tools are useful for investigating this sort of issue.
Each time when the app is clicked from oka, it tries to login to the app as there is a redirect url which goes to saml auth. But even though there is an active session in a tab it still creates a new session and invalidates the old one.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com, also mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
If I understand you correctly, the user is at Okta and clicks a link to SSO to your application. The user is then prompted to login at your application.
Is that correct?
[quote][/quote]
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com, also mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
If I understand you correctly, the user is at Okta and clicks a link to SSO to your application. The user is then prompted to login at your application.
Is that correct?
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
If I understand you correctly, the user is at Okta and clicks a link to SSO to your application. The user is then prompted to login at your application.
Is that correct?
Yes, it auto logs the user but the session is a new one meaning it has a new session id due to which the old tab which was opened earlier get invalidated.
Your application can control this. If the user is already logged in and you receive an SSO message from Okta, you don’t have to create another authentication session if it makes sense to keep the existing authentication session. Our library doesn’t get involved with the authentication sessions/cookies. This is the responsibility of the application. Of course, all instances of the browser, including multiple tabs, will share the same authentication cookie.
[quote][/quote]
Your application can control this. If the user is already logged in and you receive an SSO message from Okta, you don't have to create another authentication session if it makes sense to keep the existing authentication session. Our library doesn't get involved with the authentication sessions/cookies. This is the responsibility of the application. Of course, all instances of the browser, including multiple tabs, will share the same authentication cookie.
Ok thanks...is there a prefilter where i can verify this check and perform redirection?
Your application should be able to check whether the user is already logged in (ie there’s an authentication session). It’s not something the SAML library is aware of or manages.
[quote]
[/quote]
But how to validate if the user is already logged in? How can i identify if the cookie or session has user who is already logged in? The session id is different when i print it. This is before the login is actually triggered.
That depends on the authentication mechanism you’re using. If there’s a way to login the user, there must also be a way for you to check if the user is already logged in. Presumably there’s an authentication cookie keeping track of this.
By session ID do you mean the ASP.NET session? If it’s showing as a different session, this means the ASP.NET session cookie isn’t being sent by the browser. I suggest using the browser developer tools to see why the browser isn’t sending the cookie.