...

Recent Opmantek applications releases have introduced a simple form of cross-server Single-Sign-On (which is not enabled by default). This page describes the configuration and operational characteristics of this SSO setup.

Requirements

1. One or more On every node that should be subject to SSH, at least one of your (commercial) Opmantek Application releases must be newer than 12 Nov 2015.
   As our applications share a common core, the SSO capabilities become available as soon as you upgrade or install one sufficiently new product release.
   A simple test without checking application version numbers is to look for the property "auth_sso_domain" in /usr/local/omk/install/opCommon.nmis;
   if it's present (but blank or undef) then your installation is SSO-capable.
2. All servers in question must share a common DNS domain, and all servers must be accessed via their fully qualified DNS names within that domain.
   This is because our current SSO setup relies on an HTTP cookie that is shared between nodes in the same domain.
3. All servers in question must have at least one shared application secret in their omkd_secrets config properties.
   This is definitely the case if you use the default for this configuration propertyPleases note that all Opmantek software released after 27 October 2016 set the application secret to a unique new value on installation or upgrade; to enable SSO you have to change the first entry under omkd_secrets to the same value on all your nodes. For maximum security we recommend that you configure a single application secret only.

Configuration

To enable SSO you need to edit the configuration file /usr/local/omk/conf/opCommon.nmis, set the 'omkd_secrets' to your shared secret, and set the 'auth_sso_domain' property to your desired DNS domain with an extra leading ".", like in the example below:

%hash = (
  'authentication' => {
    # ...other stuff
    'auth_sso_domain' => '.opmantek.com',
    # ...lots of other stuff
  'omkd' => {
    'omkd_secrets' => [
      'theseareNOTthesecretsyourelookingfor',
    ],

The configuration in this example instructs the authentication code component to generate an authentication/session cookie that is shared sharable among all nodes in or under opmantek.com: the SSO domain property instructs the browser to submit this cookie when accessing a node within the domain, and the application secret ensures that all nodes can decode the cookie.

After setting this up you need to restart the Opmantek Daemon with sudo service omkd restart. Under certain circumstances It may also be required to delete all your browser cookies when switching  from per-node sign-on to SSO.

 Please note:

• Setting up SSO has to be done at least one of your involved servers, not necessarily all of them.
  The first system with SSO on that you log in to will create a session cookie for subsequent server accesses, regardless of whether these other servers have SSO enabled, and as long as all your nodes share the same application secret, the SSO session cookie will be accepted by them.
• Our SSO setup with a shared domain strictly requires that your shared domain has at least two DNS name components.
  Hence, using test.mydomain.id.au would work for nodes a.test.mydomain.id.au, an.other.test.mydomain.id.au and so on.
  However, attempting to set the SSO domain to .com or .au will not work.
• SSO across Opmantek Applications and servers is not supported by opMaps, opFlow 2 or NMIS at this point.
• The authentication code component logs SSO-related issues to log/opDaemon.log.

...