Hi xSM,
Yes, that is a valid solution and what Broadcom recommends to achieve single sign-on in a multi-domain environment.
The way it will work in your environment is when an unauthenticated user requests a resource in app.appdomain.com (this will be the Resource domain while login.logindomain.com will be the Master cookie domain), the web agent will check to see if a cookie provider is configured. Since one will be configured the app.appdomain.com web agent will redirect the user to the cookie provider. If the cookie provider receives a valid session cookie with the request, the cookie provider will redirect the user back to the protected resource with encrypted session information in the query string. This allows the app.appdomain.com agent to set a session cookie for the appdomain.com domain and make an authorization decision for the user.
If no session cookie is presented when the user is first redirected to the cookie provider, the cookie provider will redirect the user back to the protected resource with SMSESSION=NO in the query string. This tells the app.appdomain.com agent to authenticate the user per the realm's auth scheme, and then share the session information with the cookie provider. Thus, the user will be redirected back to the cookie provider one more time for the cookie provider to obtain the session information and create a session cookie for the user in the login.logindomain.com domain. The user is then redirected back to the protected resource where the app.appdomain.com agent can make an authorization decision.
As you can see, when a cookie provider is in play the system will try to make sure the authenticated user has a session cookie in the master cookie domain at all times. This is how the user can have SSO in a multi-domain environment, allowing the user to move between domains without re-authenticating.
Regards,
Pete