search

canada-ca / CATS-STAE

Cyber Authentication Technology - Technologie d’authentification électronique
https://canada-ca.github.io/CATS-STAE/
14 stars 1 forks source link

We need a better way to pass session language #8

Open harrdou opened 6 years ago

harrdou commented 6 years ago

SAML does not provide a means for SPs and IdPs to communicate the user's session language. CATS 2.0 used a common domain cookie for this, but that mechanism was chosen to work within the technical limitations of the time.

Modern browsers support technologies such as HTML5, AJAX and CORS. These should make it possible to come up with a simpler solution.

harrdou commented 4 years ago

The common domain cookie currently used to pass session language between SAML RPs and IDPs meets all of the modern definitions of a tracking cookie. All of the browsers are being enhanced with new features designed to block such cookies. E.g.:

Clearly, the days are numbered for our language cookie in its current form, and the options to maintain this functionality involve significant disruption to federation members. For example, some of the more viable options would be to:

1) Completely abandon SAML and migrate to OpenID Connect (which supports language passing). 2) Migrate all GC online services to the canada.ca domain (unlike gc.ca, canada.ca is not on the public suffix list) so the cookie would no longer be third party. 3) Create our own profile of the SAML Web Single Sign on Profile that supports language passing in Authentication Requests, and replace all the proprietary SAML software that can't support it (i.e. ADFS, SiteMinder, GetAccess) with open source software that can.

Personally I think 1) is the way to go. Poor user experience may be the motivator that makes it happen.

ricardosaracino commented 4 years ago

this was solved on my end with end extra (302) redirect on the common domain. Is it ideal, probably not.

Off the top of my head i think this is the flow csc -> common (set cookie) -> common -> csc -> idp

harrdou commented 4 years ago

Here's my latest thinking on doing away with the language cookie in CATS 3.0, based our experience implementing language passing in Sign In Canada over the last few months.

1) Authentication requests sent via the HTTP Redirect Binding would have to include a ui_locales query parameter, a-la OIDC, along with the traditional SAMLRequest, SigAlg, and Signature parameters. 2) SAML Responses sent via the HTTP Post binding would include both a locale query parameter, as well as a locale attribute in the SAML Assertion.

What we've found during our implementation is that adding a query parameter to an HTTP redirect can be very easily done by the RP web server, without any changes to (or involvement of) the underlying SAML service provider. The web server can set the value of the parameter based on an application cookie, or based on a pattern in the URL (e.g. "XXX-en.htm", XXX-fr.htm").

Likewise, the RP web server can easily extract the language query parameter from the SAML Response, and use its value to modify an application language cookie, re-write the URL or whatever the application needs to display the correct language.

Some purists might argue that it is "HTTP sacrilege" to include a query string in the URL of an HTTP Post, but it works. If an implementer really didn't like the idea then they would be free to pull the language from the SAML Assertion, like we did in the days of CATS 1.0 and Access Key.

I have successfully prototyped this with Apache httpd using mod_headers and mod_substitute and it works great. I see no reason why the IIS URL Rewrite Module 2.0 can't also accomplish this.

There is clearly more work to be done testing this approach with various technologies, but I just wanted to share my current thinking. Feedback is always welcome.

harrdou commented 3 years ago

This looks interesting.. https://github.com/privacycg/first-party-sets

ricardosaracino commented 3 years ago

I would suggest a url param