000025388 - Flash documentation update

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000025388
Applies ToFlash
Domain names
Installation Guide section 6.1.4.5
RSA Adaptive Authentication 5.7
Adaptive Authentication 2.2
Web services application
Stand alone application
IssueFlash documentation update
Flash domains need to be set
ResolutionRevision to Integration Guide, Section 6.1.4.5

Customers should be advised that the cookie and Flash domains must be verified as part of a production shakeout, since load-balancing/proxy and domains are generally different in production environments than in the test environments that they do their testing in. In addition, section 6.1.4.5 ("Domain Scoping") omits details about the use of the CookieDomain settings. These settings are used for stand alone, java API, and web services implementations that use pmsdklite.jar, specifically when using the call to PassMarkDeviceSupportLite.setDeviceCookie to set cookies. If customers are setting their own cookies settings, they will need to adjust the domain level themselves.

Lets take an example:

Assume the customer is starting with a URL suffix of olb.largebank.com

Assume an application-server farm, with servers s1, s2, and s3.

Once the user's session is load-balanced/directed to a specific server, two different approaches are used to maintain server affinity:

1. The browser continues to see URL references to https://olb.largebank.com and the load-balancer/proxy (in the financial institutions DMZ) is responsible for routing to the appropriate application server, typically done via session cookie, SSL session ID, or some other token embedded in URL filepath. In this case, no special configuration is needed.

2. The user's browser will see a URL reference that exposes the name of the specific server that they are bound to and the load-balancer/proxy can be "dumb" and just route to the appserver specified in the base URL. In this case some special configuration is needed in the application-context.xml file as follows:

<bean id="httpUtils" class="com.passmark.security.support.HttpUtils">
  <property name="internalCookieDynamicDomain">
    <value>2</value>
  </property?
</bean>

The property can be set to these values:

Positive numbers:
Tells application to use that number levels of URL domain from the right end. In the case of olb.largebank.com, if the value is 2 then the cookie will be set for the URL largebank.com. If the value is 3 then the cookie will be set for the URL in olb.largebank.com.

Negative numbers:
Tells application to use that number levels of URL domain from the left end. In the case of s1.olb.largebank.com, if the value is -1 then the cookie will be set for any URL ending in .largebank.com. If the value is 3 then the cookie will be set for any URL ending in .olb.largebank.com.
Legacy Article IDa31593

Attachments

    Outcomes