PicketLink -- identity provider behaviour in a cluster?

[jeanluc]

I'm wondering how the interaction between PicketLink and an SSO identity provider (OpenSSO in my case) plays when there are >1 instances of JBoss (5.1) behind a load balancer servicing the http requests from users.

Issue 1

The definition of a service provider (inside external-authentication-config.xml). I'm not concerned about attributes whose names end up in Url  because they will ultimately be sent to the user's browser so they  should reference the external, load-balanced, URL.

• I do wonder about the URL of the web server broken down into its components (protocol, hostname and port). Should these be different for each web server instance?
• What about serviceProviderEntityId? Should it be one per cluster (after all it's an ID, not parsed as an entity) or separate?

<ServiceProvider
            protocol="http"
            hostname="web.server"
            port="8180"
            unsolicitedAuthenticationUrl="http://web.server:8180/myapp"
            loggedOutUrl="http://web.server:8180/myapp"
            failedAuthenticationUrl="http://web.server:8180/myapp/FailedAuthenticationPage.seam"
            internalAuthenticationMethod="#{authenticator.internalAuthenticate}">

        <SamlConfig
                serviceProviderEntityId="http://web.server:8180/myapp"
                defaultIdentityProvider="http://web.server:8180/opensso"
                keyStoreUrl="file:///home/myuser/opensso/keystore.jks"
                keyStorePass="changeit"
                signingKeyAlias="signing-alias"
                signingKeyPass="changeit">
            <SamlIdentityProvider entityId="http://web.server:8180/opensso"/>
        </SamlConfig>
    </ServiceProvider>

Issue 2

I don't have a full grasp of SAML yet but I do wonder whether the SSO server ever initiates a request for a web server (such as to notify the web server to kill a session because the SSO admin did so). This cannot hit the load-balanced URL because it would ultimately reach only one server (the one chosen by the load balancer). Thus, I incline towards defining a federation with a service provider for each web server instance.

Are there any issues with the above considerations? Or other comments or gotchas?

Thanks in advance,

JL

[marcelkolsteren]

Good point. The impact of clustering on the PicketLink Seam module has not been investigated until so far.

I don't have practical experience with load balancers, but I know of a load balancing approach that uses "sticky sessions". The load balancer then ensures that all requests belonging to the same session will be handled by the same web server instance. This prevents that session info needs to be synchronized between instances. For my analysis, I'll assume that sessions are sticky.

Issue 1

• Protocol, hostname and port determine the URLs where the SAML Service Provider services will be running. They don't have to be different for each web server instance. All web server instances will just have the same configuration and the same meta data. You will upload the meta data once to the identity provider.
• One entity id for the cluster. For the outside world (and thus also for the identity providers) the service provider will seem to be one server.

Issue 2

In the context of the PicketLink Seam module, all requests are handled using the SAML redirect or the SAML post protocol binding. That means that all requests are handled indirectly through the user agent (the browser of the end user). This also includes the single logout case. Suppose that a user is logged in through SAML in application 1 and 2, where application 2 is load balanced. The end user triggers a single logout by pushing a logout button in application 1. This results in a single logout request sent to the identity provider through the user's browser. The identity provider knows that the user is also logged in in application 2, but doesn't know what is the session id of that session. That session id is only stored in a cookie in the browser, which is linked to the domain of application 2. The identity provider sends a logout request to application 2, using a browser redirect or a form post. Because the indirection via the browser, the request that hits application 2 will come in with a session cookie that sticks to the server instance that originally started the session, so the request will end up in the correct service provider instance. I don't see problems here, when all applications share the same service provider configuration.

My conclusion is that, if you use a sticky session approach, the SAML single sign on and single logout would probably work, if you use the same configuration in all web server instances.

[jeanluc]

Thanks Marcel, I'll give it a try in the next weeks.