{"id":10835,"date":"2013-10-01T18:11:39","date_gmt":"2013-10-01T12:41:39","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=10835"},"modified":"2017-04-24T16:06:12","modified_gmt":"2017-04-24T10:36:12","slug":"spring-security-cross-domain-authentication","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/spring-security-cross-domain-authentication\/","title":{"rendered":"Spring Security & Grails: Cross domain authentication from HTTP to HTTPS"},"content":{"rendered":"

\"spring_security_login\"<\/a>We were trying to implement SSL-based login and registration (i.e. HTTPS) in an e-commerce web application which was otherwise using the non-secure protocol (i.e. HTTP) for the entire website.<\/p>\n

Instead of moving the entire web application to SSL, which would have increased response times, we thought it would be best if only the authentication part of the web application could be moved to be SSL. However, this also posed an even bigger problem of cross-domain authentication since the protocol was shifting from non-secure (HTTP) to secure pages (HTTPS).<\/p>\n

As you all know, Spring Security uses an internal URL (\/j_spring_security_check) for authentication purposes that is provided out of the box. So our first attempt at cross-domain authentication was via AJAX. But we soon gave up that solution because of how cross-domain operates in the real world.<\/p>\n

How cross domain requests operate<\/h4>\n

Whenever you’re making a cross-domain AJAX call, the following happens:<\/p>\n

    \n
  1. A pre-flight request is sent first (an OPTIONS request) to ensure that the domain making the request is allowed to make the request to the domain receiving the request.<\/li>\n
  2. If the receiving domain sends back a response header containing the “Access-Control-Allow-Origin”, then the subsequent GET\/POST request is sent and the normal flow starts.<\/li>\n<\/ol>\n

    Now Grails doesn’t support a CORS request out-of-the-box according to this issue. So we have a wonderful plugin to do just that. But it doesn’t seem to be able to add CORS headers to the Spring Security plugin. So I had to give up the AJAX-ified approach and started looking towards an iframe based approach.<\/p>\n

    1. Change the login form<\/h4>\n

    [code]
    \n&lt;form action=&quot;https:\/\/localhost:8443\/j_spring_security_check&quot; method=&quot;POST&quot; name=&quot;loginForm&quot; target=&quot;hidden_iframe&quot;&gt;
    \n &lt;input type=&quot;text&quot; name=&quot;j_username&quot; \/&gt;
    \n &lt;input type=&quot;text&quot; name=&quot;j_password&quot; \/&gt;
    \n&lt;\/form&gt;<\/p>\n

    &lt;iframe style=&quot;display: none;&quot; name=&quot;hidden_iframe&quot; width=&quot;320&quot; height=&quot;240&quot;&gt;&lt;\/iframe&gt;
    \n[\/code]<\/p>\n

    What the above code does is that it sends a POST request to the requested URL and loads the response in the iframe instead of redirecting the page.<\/p>\n

    2. Change the Spring Security plugin config<\/h4>\n

    We were using the wonderful Spring Security plugin for authentication which is highly configurable. We changed the authentication success and failure URL’s to redirect to our custom GSP’s.<\/p>\n

    [code]
    \ngrails.plugins.springsecurity.failureHandler.ajaxAuthFailUrl = ‘\/login\/denied’
    \ngrails.plugins.springsecurity.successHandler.defaultTargetUrl = ‘\/login\/authsuccess’
    \n[\/code]<\/p>\n

    3. Change content of required GSP’s<\/h4>\n

    denied.gsp<\/code><\/p>\n

    [js]&lt;script type=&quot;text\/javascript&quot;&gt;\/\/ &lt;![CDATA[
    \n window.top.postMessage( JSON.stringify({signin: ‘error’}), &quot;*&quot; );
    \n\/\/ ]]&gt;&lt;\/script&gt;
    \n[\/js]<\/p>\n

    auth.gsp<\/code><\/p>\n

    [js]&lt;script type=&quot;text\/javascript&quot;&gt;\/\/ &lt;![CDATA[
    \n window.top.postMessage( JSON.stringify({signin: ‘success’}), &quot;*&quot; );
    \n\/\/ ]]&gt;&lt;\/script&gt;
    \n[\/js]<\/p>\n

    The postMessage method is a special Javascript method for cross-iframe communication. The first argument is the data that needs to be posted, and the second argument is the domain to which the data should be sent. When you specify “*”, it means it will be sent to all domains and can be caught by any event listener that can listen to the event generate.<\/p>\n

    4. Modify page containing the login form<\/h4>\n

    Add the following piece of javascript to catch the event that’s being generated by the hidden iframe.<\/p>\n

    The code is being picked up from David Walsh’s blog to provide cross-browser event compatibility. Thanks David!<\/p>\n

    [code]
    \n\/\/ Create IE + others compatible event handler
    \nvar eventMethod = window.addEventListener ? &quot;addEventListener&quot; : &quot;attachEvent&quot;;
    \nvar eventer = window[eventMethod];
    \nvar messageEvent = eventMethod == &quot;attachEvent&quot; ? &quot;onmessage&quot; : &quot;message&quot;;<\/p>\n

    \/\/ Listen to message from child window
    \neventer(messageEvent,function(e) {
    \n console.log(‘parent received message!: ‘, JSON.parse(e.data));
    \n \/\/ Do additional processing of data received
    \n},false);
    \n[\/code]<\/p>\n

    And there you are. You have a perfectly working cross-domain authentication mechanism in place that’s integrated with Grails, Spring Security, and JavaScript.<\/p>\n","protected":false},"excerpt":{"rendered":"

    We were trying to implement SSL-based login and registration (i.e. HTTPS) in an e-commerce web application which was otherwise using the non-secure protocol (i.e. HTTP) for the entire website. Instead of moving the entire web application to SSL, which would have increased response times, we thought it would be best if only the authentication part […]<\/p>\n","protected":false},"author":33,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":8},"categories":[2026,7],"tags":[1221,1222,227,1157,1220,4841,672,824],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/10835"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=10835"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/10835\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=10835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=10835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=10835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}