PortalProtect Session Cookie

In order to keep track of a user session, PortalProtect uses a secure session cookie, that is only kept in memory in the browser.

This cookie is tied to the domain which it came from, and it is impossible for the browser to send the same cookie to another domain.

If the session with PP originated from www.primarysite.com, then the session cookie will only be sent back to www.primarysite.com, but never to www.secondarysite.com.

Note that the browser is able to send the same cookie to both www.server1.site.com, and www.server2.site.com since they are just different servers on the same domain, which is site.com.

So, the browser does not share cookies between different domains.

Cross-Domain Cookie Sharing

Often, it is necessary to share information between servers running on different domains, even though the browser does not support it directly, fortunately there is a way to fool the browsers into obtaining the same cookie value for each domain, even E-Business and e-Commerce has changed requirements, so all companies now need to conduct online business with users and business partners alike. This means that companies are forced to deploy a multitude of different servers, applications and services. These servers are now mission critical and support the companies business requirements, and therefore companies depend on these servers to be operating, and it is of the utmost overwhelming importance that clients see the company as a whole, and not as a number of different parts.

Unfortunately, it is not an easy job to keep a multitude of applications and servers alive, and also make sure that they are secured and present a whole and interesting experience to clients, so they will keep coming back. to the portal.
Implementers of e-Business infrastructure commonly run into the following problems: 

Partner Login

If you need to share the session information with a remote partner that does not have PortalProtect, you can still do it.

The secured cookie contains the PP session ID, as well as the userid and username, this means that you can share the user's identity with a 3rd party, even if they do not run PortalProtect.

If you need this functionality, contact IT Practice to get the correct code to use at the partner site to decrypt the cookies.

If your partner also uses PortalProtect or you internally have more than one Session Controller domain PortalProtect supports generating a secure ticket that can be sent to the other PortalProtect session controller domain with information on userid, username, groups, state variables and more. This allows you to transfer much of the information in one session to another Session Controller domain giving the user access to that (if allowed by the other domain). 

Configuration

In order to use cross-domain cookie sharing PortalProtect must be configured to do so.

For added security, domain redirect cookies are encrypted using the source domain's private key, and the target domain's public key. When the encrypted cookie reaches the destination, it is decrypted first with the target domain's private key, and then with the source domain's public key.

This double encryption/decryption ensures that no other party than the two involved sites are able to read the contents of the secure cookie, thus making it safe to transmit even over unsecured channels.

In the PortalProtect configuration, the SessionController needs to have a few new entries.

• "domain.list" must contain a list of configured domains, e.g. "www.primary.dk,www.secondary.dk".

For each domain listed, two new properties must be added to the configuration.

• "domain.<domainname>.privatekey" – points to the private key, and associated password.
• "domain.<domainname>.targets" – points to a list of remote domains reachable from this domain, with their assocated public keys.

Here is an example of the XML configuration – replace ###CFGPATH### with the path to where the keys are stored.

<group name="crossdomain" description="Cross-domain session support">
  <property name="domain.list" value="www.primary.dk,www.secondary.dk" description="The list of domains that this server supports"/>
  <property name="domain.www.primary.dk.privatekey" value="###CFGPATH###/primarysite.pri,password" description="The file and password of the primary key"/>
  <property name="domain.www.primary.dk.targets" value="www.secondary.dk,###CFGPATH###/secondarysite.pub" description="List of targets and their public keys"/>
  <property name="domain.www.secondary.dk.privatekey" value="###CFGPATH###/secondarysite.pri,password" description="The file and password of the primary key"/>
  <property name="domain.www.secondary.dk.targets" value="www.primary.dk,###CFGPATH###/primarysite.pub" description="List of targets and their public keys"/>
</group> 

To generate a set of private an public key, you must execute the java class "dk.itp.security.securedataexchange.GenerateKeypair" – it takes 3 arguments, the name of the private key file, the name of the public key file, and the password. The password can be obfuscated/encrypted (see Encrypting or Obfuscating Passwords) if you do not want to type in a cleartext password on the command-line.

Be sure to keep the private key protected, and only give away the public key to others.
If you need cross session controller domain logon some extra configuration in addition to the above is needed. What you need to configure is the enablement of cross-domain login and the rules applied to it.

Sender domain:

<group name="crossdomain" description="Cross-domain session support">
  <property name="domain.www.primary.dk.crossdomain.enable" value="true" description="Enable/disable cross-domain for this domain"/>
  <property name="domain.www.primary.dk.crossdomain.transfergroups" value="true" description="Enable/disable group transfer"/>
  <property name="domain.www.primary.dk.crossdomain.transferanonymoussessions" value="true"  description="Enable/disable anonymous transfers"/>
  <property name="domain.www.primary.dk.crossdomain.transferstatenames" value="state1,state2,state3" description="List of state names to transfer"/>
</group> 

Receiver domain:

<group name="crossdomain" description="Cross-domain session support">
  <property name="domain. www.secondary.dk.crossdomain.enable" value="true" description="Enable/disable cross-domain for this domain"/>
  <property name="domain. www.secondary.dk.crossdomain.overwriteloggedonsessions" value="false" description="Enable/disable overwriting of logged on sessions"/>
</group> 

On the receiver site you also need to configure the cross-domain authentication plugin as part of your authentication plugin list.

<property name="server.authenticationplugins" value=". . . . ,dk.itp.security.authentication.CrossDomainAuthenticationPlugin, . . . " description="The list of authentication plugins (classes) to load"/> 

Encoding Redirect URL

To encode an URL that redirects to another server, execute the following code:

String token = PTServer.getInstance().getEncryptedSessionCookie(sessionId, "https://www.secondarysite.com/redirfrompp.jsp", "www.primarysite.com", "www.secondarysite.com");
partnerurl = "https://www.secondarysite.com/.domainRedirect?source=www.primarysite.com&id=" + java.net.URLEncoder.encode(token);

This code first creates a token, containing the encrypted session ID, as well as the userid and username of the user who has the given session. It also contains the new URL to redirect the user to. 

After creating the token, the new URL is created – it redirects the user to the secondary domain, and uses the special URL ".domainRedirect" – this is intercepted by the PP Dispatcher (or Ceptor Gateway if the appropriate session resolver plugin is installed), which automatically decrypts the token, and assigns the contained session ID to the user – after doing this, the user is redirected to the URL contained in the token, after which his session with the secondary site is established, and can be used normally.

If you need to do cross session controller domain logins you can generate the ticket for a cross-domain login with the following code. It is shown here as a standard JSP HREF link. This does however have limitations on Internet Explorer since it only handles 1024 byte request strings. So you should use a POST mechanism to send the request instead if you are transferring groups and/or state variables since they quickly take up space:

<a href=http://www.secondary.com/remotelogon.jsp?session= + <%=Agent.getInstance().getCrossDomainSession( PPSession, "site2" )%>Link to www.secondary.com</a> 

On the receiver site you can unpack this ticket like this (in a servlet, JSP or what you need):

try {
  Agent.getInstance().logon( PPSession, AuthTypes.AUTHTYPE_CROSSDOMAIN, request.getParameter( "session" ) );
} catch( Exception e ) {
  // Standard error handling for your application
}