Referral KeyServer Configuration
K2's Referral feature is a way for departments at sites with enterprise-wide KeyServers to own and administer a small departmental KeyServer supporting applications over which they have immediate control. The departmental KeyServer can be set up to refer its clients to the site-wide KeyServer, and thus clients will be able to use programs that are managed by either KeyServer. Note however, that this same basic goal might be better accomplished in K2 v7.4 through the use of Sections, which allow federated management within a single KeyServer, while also allowing an Enterprise level Administrator visibility into all Sections. We recommend using Sections within a single KeyServer, as opposed to Referral KeyServers - read more about Sections here.
The ability to connect to two KeyServers at once has obvious advantages at sites with more than one KeyServer. Users can have access to applications supported by separate KeyServers without having to switch logons between them and can simultaneously use programs managed by different KeyServers.
A large company for example might have an enterprise-wide KeyServer supplying the basic applications available to every employee in the organization. Some individual departments might have their own software budgets and need applications not supported organization-wide. Each department can set up its own KeyServer and refer the departmental clients to the corporate KeyServer. This allows each department to efficiently buy, implement and upgrade software of their own without having to worry about managing policies for software that is better managed centrally for the entire company.
Another example might be a university with a campus-wide KeyServer from which students and faculty access general-functionality applications. The people in the Mathematics department might have a mathematical modelling program that requires local implementation and metering, and they would therefore want a small departmental KeyServer that gives them control over the program purchased under their own budget. This departmental KeyServer could in turn refer its clients to the more general campus-wide KeyServer.
Note the enterprise KeyServer needs to support enough clients to handle not only the clients logged directly onto it, but all the departmental clients as well. A KeyServer with 50 directly logged on users that also has four 10-client referrals could have as many as 90 clients requiring access at any given time.
When KeyAccess logs on to a KeyServer it may receive with its connection a “referral” to a second KeyServer. Upon receipt of a referral, KeyAccess logs onto the second KeyServer as well as the first (and will do so again at each restart). When a user at that computer launches a managed program, KeyAccess asks both KeyServers about policy availability, and requests the policy from the appropriate KeyServer. As with any policy request from KeyServer, this all happens transparently to the user.
The user does not need to take any action in order to be logged onto the enterprise KeyServer. The only case where the user must be aware of the connection to the enterprise KeyServer is if that server requires name and password authentication.
KeyServer Referrals are almost entirely client-driven. Once an administrator configures his or her KeyServer to refer to another KeyServer, and after the connection is validated by the momentary acquisition of a special policy from the enterprise KeyServer, the two KeyServers do not communicate again unless the referring KeyServer process is restarted (at which point it again requests permission to refer).
All the rest of the work is done by KeyAccess, which connects to both KeyServers at startup, asks both KeyServers about availability when a managed program is launched, and requests a policy from the appropriate KeyServer based on the reply provided by each.
If you want to refer your KeyServer clients to a second KeyServer, use the Change Referral command in KeyConfigure's Config Menu. The KeyServer Referral dialog appears
By default, referrals are turned off. Check the Refer Clients to an Additional Server box and in the Location field, enter the network name or address of the KeyServer to which you will refer clients. Enter a name and password if the enterprise KeyServer requires this information.
OPEN Referral dialog
Click Apply or OK after filling in the location of the enterprise KeyServer. Your KeyServer will attempt to connect to the enterprise KeyServer and get permission to refer clients.
This process involves getting and returning a special policy from the enterprise KeyServer and therefore allows for the referral to be authenticated against just like any other request for a policy. The administrator of the enterprise KeyServer can use any of the standard authentication methods (Network Access, Groups/Pools, Passwords) to control which KeyServers may refer their clients. If a name/password based authentication is in place on the enterprise KeyServer, then you must enter proper name and password values in the KeyServer Referral dialog for the referral to work.
If for some reason your KeyServer cannot obtain permission for the Referrals Policy from the enterprise KeyServer, it will not refer its clients to that server.
By default, your KeyServer does not have the “Referrals” Policy installed. To enable referrals, you must install this special policy. To do so, open the “Extra Licenses” file in KeyConfigure. The Administrative installer puts this file in the “Misc” folder, which is in the same folder as KeyConfigure. Then connect to your KeyServer. Put a checkmark next to the Referrals product and policy, then click Import. Your KeyServer now supports the “Referrals” policy, and all that is left to do is configure the policy as you wish.
Any KeyServer can allow or disallow other KeyServers to refer their clients to it. Whenever another KeyServer is set up to refer to your KeyServer, it must periodically request permission from your KeyServer. You manage who gets permission by changing the “Referrals” Policy on your KeyServer. By using policy pools, authentication, and network access filters, you can control which KeyServers may refer their clients to your KeyServer. To disallow all such referrals, set the limit of the Referrals Policy to zero.
Your KeyServer will write to its usage database every time another KeyServer obtains permission to refer its clients. You can use KeyConfigure's reports to see who (which KeyServers) have requested permission to refer their clients to your KeyServer.
An enterprise KeyServer makes only one type of notation in its logs to reflect the fact that it is supporting referred users, and that is the record of the Referrals Policy being granted to the address of the referring KeyServer.
As you would expect, any KeyShadows you set up for your KeyServer will act independently of other KeyServers and their shadows. If a client is connecting to multiple KeyServers, and one of those servers goes down, the client will search for and connect to one of that server's shadows. When deciding which server to get a policy from, KeyAccess will always prefer a real server to a shadow, even if the shadow has more policies available.
It is important to note that KeyServer's Referral feature is not “load balancing” in any sense -- since KeyServer puts no limits on the number of copies or location of an application, and since KeyServer's response time is very fast on even the slowest networks, KeyServer has no need to impose the administrative burdens associated with load balancing, even when applications are installed multiple times across multiple file servers under heavy load.
It should also be stressed that KeyServer Referrals are not reflexive: if KeyServer A refers its clients to KeyServer B, that does not mean that KeyServer B's clients will thereby turn around and request policies from KeyServer A (unless the two KeyServers are configured explicitly to refer to each other).
In the examples above, if there were ten departmental KeyServers, all ten could refer to the central KeyServer. Each departmental user would simultaneously have access to their local departmental KeyServer and to the enterprise KeyServer, but would not have access to the software managed by the KeyServers in the other nine departments. Also, any clients logged directly onto the enterprise KeyServer would only have access to that KeyServer's policies, as the enterprise KeyServer is not referring clients to any other KeyServer.