Clever Geek Handbook

SAML Behavior When Using an HTTP Server for High Availability

I have implemented SOML SSO support so that my application acts as a service provider using the Spring Security SAML Extension. I was able to integrate my SP with various IDPs. So for example, I have HostA, HostB and HostC , they all have different instances of my application. I had an SP metadata file specified for each host and set the AssertionConsumerServiceURL with the url of that host (EX: https: HostA.com/myapp/saml/sso). I added every metadata file to IDP and tested them all and it works fine.

However, my project also supports high availability by having the IBM HTTP Server configured for load balancing. So in this case the HTTP server will configure the hosts (A, B, C) to be used for load balancing, the user will access my application using the HTTP server url: https: httpserver.com/myapp/

If I defined one SP metadata file and had the HTTP server url specified in AssertionConsumerServiceURL ( https://httpserver.com/saml/sso ) and changed my implementation to accept assertions targeting my HTTP server , that would be the result of this script:

  • The user accesses the HTTPServer that sent the user to HostA (behind the scenes).
  • My SP application to HostA sends an IDP request for authentication.
  • IDP sends the response to my httpserver as: https://httpserver.com/saml/sso .

Will the HTTP server be redirected to HostA so that it looks like this: https://HostA.com/saml/sso

Thank.

+3


source to share


1 answer


When deploying the same application instance in clustered mode behind a load balancer, you need to instruct the internal applications of the public url on the HTTP server ( https://httpserver.com/myapp/ ) they are deployed behind. You can do this using SAMLContextProviderLB

(see manual for details ). But you seem to have already completed this step successfully.

Once your HTTP server receives the request, it will send it to one of your hosts to the url, eg. https://HostA.com/saml/sso and will usually give the original URL as the HTTP header as well. SAMLContextProviderLB

will force the SP application to think the real url was https://httpserver.com/saml/sso , which will force it to pass all SAML security checks associated with the URL destination.



Since operating systems store state in their HttpSessions, be sure to do one of the following:

  • enable sticky session on the HTTP server (so that related requests are always directed to the same server
  • make sure to retry the HTTP session across your cluster.
  • disable response id validation by including the bean EmptyStorageFactory

    in your Spring config (this setting also disables single logout capability)
+4


source






More articles:


All Articles