Difference between revisions of "Session Sharing"
m (1 revision imported) |
|
(No difference)
| |
Latest revision as of 12:52, 11 May 2017
Contents
Introduction
From version 3.9.5 onwards, Session sharing is included as part of Appliance Synchronisation. See Also Single Channel Session Cache.
This white-paper explains the session sharing feature that was added in Version 3.5 of Swivel. It explains what this feature is, why you may wish to and how to implement and enable it on Swivel instances (it is not enabled by default).
Note also that PINsafe RADIUS Proxy may also be used in PINsafe 3.8 onwards as an alternative to Session Sharing.
Session Sharing Explained
For Active-Active HA pairs, when using single channel or on-demand dual channel, it has been a requirement that the user authenticates to the same server from which they retrieved the security string. This has prevented Swivel servers from being deployed in a truly load-balanced way. Active/Passive installations would not use session sharing.
Version 3.5 of the Swivel software now removes this requirement. Now when a session is started on one Swivel server, that session can be “shared” with the other Swivel server, so that either server can accept the subsequent authentication request.
The mechanism for this is that the sessions that are “in progress”, ie where a user has requested an image or message, but not yet authenticated, are stored in a cache that is shared between the two servers. In a similar way to the way that the databases are shared in a Swivel active-active configuration.
Swivel servers configured to share sessions must also share a common user-population.
The session sharing can, but need not be, used with an Active-Active pair. Clearly to support the use of this feature there must be sufficient bandwidth, with low-enough latency, between the two servers.
At the network level, session sharing uses IP Multicast, therefore it is a requirement that the network infrastructure supports multicast.
How it works
When a user uses TURing images or on-demand SMS messages to authenticate, the associated security string is only valid for a short time. When a security string is requested in either of these two ways, a session is created within Swivel. This records, in memory, all the information required to allow the user to authenticate using that security string. If the user does not authenticate in time, and the security string becomes invalid, the session is invalidated and destroyed.
Similarly if the user requests another security string, a new session is created and the previous session is deleted.
These sessions, as they are short-lived, are stored in memory rather than in a database (unlike the dual-channel security string messages sent out automatically after every authentication attempt, which are stored in the database and therefore replicated across both Swivel servers in an active-active pair).
When a pair of Swivel servers have been set up to share their sessions every time a change is made to the session cache on one server a message is sent across to the other Swivel server informing it of the change. This means that, in effect, both servers share the same session-cache.
This common view of the current active sessions means that a user can authenticate to any server.
Example.
An authentication agent (e.g. a VPN) may be configured to use either one of a pair of Swivel servers
Session sharing example
- The agent submits a request for a TURing image to the first Swivel server.
- The first Swivel server receives this request, creates the security string and the required TURing image, which is returns to the Agent.
- It then stores the details in a session that it stores in memory.
- In addition, as it is configured for session sharing it sends the details of the session it has created, via multicast, to any other Swivel servers that may need this information. NB The use of multicast means that if, for example, the second Swivel server became unavailable for some reason the first Swivel server does not waste time trying to send messages to it. It is possible to set the session sharing to use unicast, but this is not advisable.
- The second Swivel server, as it also configured for session sharing, receives this information and also creates and stores the session.
- The authentication request them is sent to the second Swivel server.
- As this second server has details of the session that was created for the user, it can authenticate the user. Once the user has authenticated the session is no- longer valid, so it is deleted.
- The second Swivel server therefore sends a message, again via multi-cast, informing any Swivel servers that the session is no longer valid.
Session Sharing Implementation
For Swivel Appliances see Enabling Appliance Session Sharing
For software installations and further assistance see the below.
Network Configuration
The Swivel servers need to be connected to a network that supports multicast traffic. Most switches are capable of supporting multicast although some switches / firewalls may be configured to block or disallow multicast.
Firewalls Settings
Note: When changing the firewall settings verify the following Known Issues before changing the firewall rules.
Any firewalls between the two Swivel servers needs to be opened to allow the messages to be passed between the servers. This includes the Linux firewalls on the appliances themselves. A rule must be added to the chain to accept traffic from the other appliance and to allow traffic to be sent to the other appliance.
The above rule means all traffic from the other server will be allowed. A better rule would just open up the multicast port being used. This is 4446 by default and is defined within the cache.xml file multicastGroupPort=4446
Primary Appliance Firewall Configuration
On the Primary Swivel appliance edit /etc/sysconfig/iptables with WinSCP:
After the line "-A RH-Firewall-1-INPUT -i lo -j ACCEPT" add the line:
-A RH-Firewall-1-INPUT -i eth0 -s 192.168.0.37 -j ACCEPT
(where 192.168.0.37 is the IP of the Standby machine. Replace this example IP address with your Standby IP)
Standby Appliance Configuration
On the Standby Swivel appliance edit /etc/sysconfig/iptables with WinSCP:
After the line "-A RH-Firewall-1-INPUT -i lo -j ACCEPT" add the line:
-A RH-Firewall-1-INPUT -i eth0 -s 192.168.0.36 -j ACCEPT
(where 192.168.0.36 is the IP of the Primary machine. Replace this example IP address with your Primary IP)
Appliance Firewall Restart
Once you've made these changes, on BOTH machines restart ipchains:
service iptables restart
Appliance connectivity and listener
You should find that you return a result when running the following netstat command:
[admin@primary ~]# netstat -an | grep 4446
udp 1520 0 0.0.0.0:4446 0.0.0.0:*
udp 0 0 0.0.0.0:4446 0.0.0.0:*
Time Synchronisation
Sessions are timestamped by the server that creates them, sessions are only valid for finite time, so the clocks on the servers must be synchronised. As clocks drift, the use of an NTP server is essential. NTP servers can be configured from the Appliance menus.
Login to the command line to check and start the NTP service if necessary:
[admin@primary ~]# service ntpd status ntpd is stopped [admin@primary ~]# service ntpd start Starting ntpd: [ OK ] [admin@primary ~]#
See the NTP servers article for further information.
Swivel Settings
There are two elements to the Swivel configuration. First you need to configure Swivel to use session sharing, then select multicast session sharing.
To select session sharing you need to edit the config.properties file, the default settings for this file for Swivel 3.6 onwards are:
SECURITY_STRING_GENERATOR = com.swiveltechnologies.pinsafe.server.utility.SecurityString SESSION_MANAGER = com.swiveltechnologies.pinsafe.server.session.LocalSessionManager
The file can can be found under one of the following locations:
- Swivel 3.9.2 onwards on appliance: /home/swivel/.swivel/conf
- Swivel 3.9.2 onwards on software: USER_HOME/.swivel/conf. Example Windows 7 c:/users/<username>/.swivel
- Swivel 3.5 to 3.9.1 or earlier: /usr/local/tomcat/webapps/pinsafe/WEB-INF/conf
- Swivel 3.5 to 3.9.1 or earlier on software: <path to Tomcat>/webapps/pinsafe/WEB-INF/conf
Note many of the transitory data settings were moved in 3.9.1, but the config.properties was moved in version 3.9.2
Take a backup up copy of config.properties
This file includes a setting for Session Manager, the default value for Version 3.5 is;
com.swiveltechnologies.pinsafe.session.LocalSessionManager and needs to be changed to com.swiveltechnologies.pinsafe.session.DistributedCacheSessionManager as shown below:
SECURITY_STRING_GENERATOR = com.swiveltechnologies.pinsafe.utility.SecurityString SESSION_MANAGER = com.swiveltechnologies.pinsafe.session.DistributedCacheSessionManager
for Version 3.6 and later the SESSION_MANAGER line needs to be changed from com.swiveltechnologies.pinsafe.server.session.LocalSessionManager to com.swiveltechnologies.pinsafe.server.session.DistributedCacheSessionManager
SECURITY_STRING_GENERATOR = com.swiveltechnologies.pinsafe.server.utility.SecurityString SESSION_MANAGER = com.swiveltechnologies.pinsafe.server.session.DistributedCacheSessionManager
To specify multicast session sharing navigate to the pinsafe/WEB-INF/classes folder. By default there will be two files related to session caching; multicast-cache.xml and peer-cache.xml.
To specify the use of multicast you need to copy the multicast-cache.xml file to cache.xml
check file permissions and ownership
Tomcat must then be restarted for these changes to take effect
Repeat this for all Swivel servers.
Once these process have completed on all servers, they should all be sharing a common session-cache.
Testing
With session sharing enabled you can request a security string from one server and authenticate to another (assuming the user exists on both servers). Therefore the easiest way to test is via the Swivel Administration Console. Enter the username in the first login page, start the session, then enter the same username and the resultant one-time code on the second Swivel server. This should succeed. Entering the same one-time code in the first Swivel server should then fail, as the session should have been deleted from both servers.
Considerations
- The protocols use for the multicast session-sharing are not encrypted. Whereas just sniffing the network will not tell an attacker any useful information, an attacker with the time, expertise and access to the network would be able determine the details of the sessions passed between the servers. However this would only reveal the details of the security strings, this attack would have be combined with an attack that captured the submitted credentials.
- You may need to enable PIM (Protocol Independent Multicast) on your switch or VLAN for Multicast to work.
Swivel Multicast is configured using the RFC implementation with Multicast and IGMP joins for a specific group or groups.
Troubleshooting
ERROR 127.0.0.1:Exception on replication of putNotification. RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.InvalidClassException: net.sf.ehcache.Element; local class incompatible: stream classdesc serialVersionUID = 1098572221246444544, local class serialVersionUID = 3343087714201120157. Continuing...
127.0.0.1:Session started for user: xyz.
This error has been seen in Swivel version 3.9.3 due to control codes in the config.properties file, care must be taken when editing such files such as using Windows third party tools.
java.lang.ClassNotFoundException:
com.swiveltechnologies.pinsafe.server.session.DistributedCacheSessionManager
org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /pinsafe threw load() exception
java.lang.ClassNotFoundException:
com.swiveltechnologies.pinsafe.server.session.DistributedCacheSessionManager
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1232)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.swiveltechnologies.pinsafe.server.config.Config.load(Config.java:87)
at com.swiveltechnologies.pinsafe.server.config.Startup.init(Startup.java:126)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3996)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4266)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:448)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
This error has been seen in Swivel 3.8 due to control codes in the config.properties file, care must be taken when editing such files such as using Windows third party tools.
