Hello,
We’re using ComponentSpace’s SAML v2.0 for .NET in an ASP.NET MVC application.
We’re having issues with our SSO implementation. Several of them appear to stem from the fact that our code uses SAMLIdentityProvider.GetPartnerPendingResponse() which seem to return stale values (leftovers from previous sessions?). (The developer who initially integrated the library is no longer working on the project.)
Surprisingly, it looks like SAMLIdentityProvider.GetPartnerPendingResponse() is not used in any of the examples provided with the library, and a Google query returns 0 result. It’s not clear why the original developer decided to use this method, and especially how this method works. Does it retrieve the partner SP from a cookie? Does it use the SSO session store?
Best,
Franz
Hi Franz
GetPartnerPendingResponse returns the name of the partner service provider to which a single sign-on or logout response is pending or null if none.
This information is maintained in the SAML SSO session state.
By default this is stored in the ASP.NET session.
Our examples are fairly straightforward and they don’t make use of this API method.
If you’re seeing stale information it’s possible that the information isn’t being cleared properly.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Also, please mention this forum post.
Hello,
Thanks for your response.
I have enabled the SAML trace but this uncovered a problem: It looks like we haven’t implemented ISSOSessionStore.SessionID (it currently throws a NotImplementedException). This prevents the full SAML trace from being generated.
Could this omission be the cause of other issues? I would expect that any use of this property would lead to crashes since it throws, but maybe the SAML library silently catches the exception…
I’ve looked into the documentation but I’m not sure where this property should retrieve the session ID from. I understand that it’s supposed to be some kind of unique user session ID, but I’m not sure how to generate it (maybe simply a GUID) but especially if/where to store it. Should it be stored into (and subsequently retrieved from) the session?
Here is our current code:
private class CookieSSOSessionStore : ISSOSessionStore
{
public string SessionID
{
get
{
throw new NotImplementedException();
}
}
public object Load(Type type)
{
var context = HttpContext.Current;
// Trying to read an earlier session state in current ASP.NET context.
if (context.Items.Contains(“SamlSession”))
{
return context.Items[“SamlSession”];
}
// Trying to read the session state from the cookie.
var cookie = context.Request.Cookies[“NameOfOurCookie”];
if (cookie != null)
{
var value = BinaryUtils.Deserialize(Convert.FromBase64String(cookie.Value));
var ssoSession = JsonConvert.DeserializeObject((string)value, type);
// Optimization to reduce number of deserializations.
context.Items[“SamlSession”] = ssoSession;
return ssoSession;
}
return null;
}
public void Save(object ssoSession)
{
var context = HttpContext.Current;
// Save the session into a cookie.
var value = JsonConvert.SerializeObject(ssoSession);
var cookieValue = Convert.ToBase64String(BinaryUtils.Serialize(value));
var cookie = new HttpCookie(“NameOfOurCookie”, cookieValue);
context.Response.Cookies.Add(cookie);
// Save the session state into the current ASP.NET context to allow reading the
// up-to-date value as long as the cookie hasn’t been returned to the browser.
context.Items[“SamlSession”] = ssoSession;
}
}
Any help or pointers would be hugely appreciated. I’ll follow up by email with our SAML trace as soon as I managed to collect it.
Thanks,
Franz
Hi Franz
The SessionID should uniquely identify the SAML SSO session.
If using the default implementation which stores SSO session state in the ASP.NET session, it’s simply the ASP.NET session ID.
If you have a custom implementation using a cookie, it could be the name of the cookie (assuming names are unique) or some value contained in the cookie.
Currently, the SessionID property is only accessed if SAML trace is enabled which is why you didn’t see the error before.
For your implementation you could simply return the cookie name.
One question I have is why is a custom ISSOSessionStore implementation being used?
The code above is storing “SamlSession” in the ASP.NET session.
If ASP.NET session support is enabled, why not use the default ISSOSessionStore implementation which stores the SAML SSO session state in the ASP.NET session?
Hi,
Thanks for the detailed answer.
[quote]The SessionID should uniquely identify the SAML SSO session.[/quote]
I’m still somewhat confused, in particular I’m not quire clear “uniquely” among what? All SAML SSO sessions on the server?
[quote]If using the default implementation which stores SSO session state in the ASP.NET session, it’s simply the ASP.NET session ID.[/quote]
Got it.
[quote]If you have a custom implementation using a cookie, it could be the name of the cookie (assuming names are unique) or some value contained in the cookie.[/quote]
Ok. I guess we would store the value in the cookie though, I don’t see how we could deal with a randomly named cookie.
[quote]Currently, the SessionID property is only accessed if SAML trace is enabled which is why you didn’t see the error before.[/quote]
Ok.
[quote]For your implementation you could simply return the cookie name.[/quote]
You mean literally “NameOfOurCookie” (which is in fact more or less the name of company + the name of our product)?
[quote]One question I have is why is a custom ISSOSessionStore implementation being used?[/quote]
That’s a good question, I wasn’t even aware that there was a default session store. Maybe it was implemented like that so that we could name the cookie the way we wanted? Can we use the default implementation but choose the name of the cookie? Actually, maybe the default implementation is using the ASP.NET session state cookie name set in Web.config? I.e.
<system.web>
</system.web>
Best,
Franz
Answering my own question:
[quote]Actually, maybe the default implementation is using the ASP.NET session state cookie name set in Web.config?[/quote]
It actually does, meaning that we can probably get rid of our ISSOSessionStore implementation.
Franz
The engineer who worked on integrating the SAML library into our project just gave me some background about our custom cookie-based SSO session store: The problem with ASP.NET sessions is that they may get disposed at any time and we have apparently no control over their lifetime. Storing the SAML session into a cookie was apparently the best solution he could find at that time.
Does that make sense to you?
Franz
ASP.NET session cookie lifetime may be controlled through configuration.
https://technet.microsoft.com/en-us/library/h6bb9cz9(v=vs.100).aspx
The default timeout is 20 minutes.
You could increase this if required.
Using the ASP.NET session cookie is the simplest approach.
Regarding your question about the SessionID property, it should be unique across all SAML SSO sessions.
However, as I mentioned, currently it’s only used for logging purposes so it’s value is not critical.
https://technet.microsoft.com/en-us/library/h6bb9cz9(v=vs.100).aspx
The default timeout is 20 minutes.
You could increase this if required.
Using the ASP.NET session cookie is the simplest approach.
Regarding your question about the SessionID property, it should be unique across all SAML SSO sessions.
However, as I mentioned, currently it's only used for logging purposes so it's value is not critical.
I should verify again, but I'm almost sure that SAML sessions are not stored in the ASP.NET session cookie by default...
You said earlier:
[quote]If ASP.NET session support is enabled, why not use the default ISSOSessionStore implementation which stores the SAML SSO session state in the ASP.NET session[/quote]
That's exactly what seems to happen by default: SAML sessions are stored in the in-process, in-memory ASP.NET session, not in the ASP.NET session cookie.
Franz
Hi Franz
That’s correct.
The ASP.NET session cookie value is used by ASP.NET to lookup the ASP.NET session data which by default is stored in process memory.
The cookie value doesn’t contain the session data itself.
The default ISSOSessionStore implementation stores SAML SSO session state in the ASP.NET session.
That's correct.
The ASP.NET session cookie value is used by ASP.NET to lookup the ASP.NET session data which by default is stored in process memory.
The cookie value doesn't contain the session data itself.
The default ISSOSessionStore implementation stores SAML SSO session state in the ASP.NET session.
Thanks for the confirmation!
So we'll stick to storing SAML sessions in cookies since we don't yet have an out-of-process session store (Redis, SQL Server...) but we're running our application on multiple servers, meaning that ASP.NET sessions can't be shared with the default ISSOSessionStore.
Franz
ASP.NET sessions can be stored centrally in SQL Server and other database servers.
However, the cookie approach sounds fine too.