Command Center SSO Installation

From Lingoport Wiki
Revision as of 23:14, 26 July 2023 by Lji (talk | contribs) (→‎Encrypting SSO Passwords)
Jump to: navigation, search

Overview

Many companies use SAML SSO with an Identity Provider to manage users and access to applications. To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center. Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf

  1. a keystore that contains the identity provider certificate and a key
  2. the idp.xml file that describes the identity provider (Okta in our example)
  3. the sp.xml file that describes the service provider (our Command Center application)

Configure the Identity Provider

We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.

Set up Okta Developer Account

Create Command Center Groups/People

  • Click Directory->Groups on left
  • Create Command Center Admin group
  • Create Command Center Manager group
  • Create Command Center Developer group
  • Create Command Center Translator group
  • Choose Directory->People on left
  • Add accounts and assign to appropriate Command Center Groups

Create Okta Application

   email, Unspecified, Email
   username, Unspecified , Username
   fullname, Unspecified , Last Name
  • Groups Section: enter in the following:
   memberOf, Unspecified, Contains, Command
  • Select I'm an Okta customer adding an internal app
  • Check This is an internal app that we have created
  • Go to Assignments tab
  • Assign the four Command Center groups to your app

Download Artifacts

  • Go to Sign On tab of your app
  • Click View SAML setup instructions
  • Download certificate
  • Copy IDP Metadata to a file named idp.xml

Generate Keys and Keystore

  • Generate key and keystore:
   keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks>
  • Accept Identity Provider Certficate
   keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta>

Generate sp.xml

  • Create a file named sp.xml with the following contents
   <?xml version="1.0" encoding="UTF-8"?>
   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://saml.lingoport.net/command-center/saml2/service-provider-metadata/<your-saml-key>">
   <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
   <md:Extensions><idpdisco:DiscoveryResponse xmlns:idpdisco="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://saml.lingoport.net/command-center/login/auth?disco=true"/> 
   </md:Extensions><md:KeyDescriptor use="signing">
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data>
   <ds:X509Certificate>CERTIFICATE</ds:X509Certificate>
   </ds:X509Data></ds:KeyInfo></md:KeyDescriptor>
   <md:KeyDescriptor use="encryption">
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data>
   <ds:X509Certificate>CERTIFICATE</ds:X509Certificate>
   </ds:X509Data></ds:KeyInfo>
   </md:KeyDescriptor>
   <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://saml.lingoport.net/command-center/saml/SingleLogout"/>
   <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://saml.lingoport.net/command-center/saml/SingleLogout"/>
   <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
   <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
   <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
   <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> 
   <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
   <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/>
   <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/>
   <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/>
   </md:SPSSODescriptor>
   </md:EntityDescriptor>
  • Modify entityId to match what you specified as Audience in your Okta app.
  • Replace the two CERTIFICATEs with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.
  • Update the various Locations to be the machine your Globalyzer Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings

Configure saml_configuration.conf

  • Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.
  • Add and configure the following lines to saml_configuration.conf:
   // tell Globalyzer and the Plugin to use saml
   commandcenter.saml.mode = true
   grails.plugin.springsecurity.saml.active = true
   grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']
   grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'

   // keystore configuration
   // assuming you created a keystore named saml-keystore.jks and a key named samlkey ...
   grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"
   grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'
   grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']
   grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'
   grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'
   grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'
   grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'

   // leave as is if created okta app as specified above
   grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'
   grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']
   grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Command Center Admin', 'ROLE_MANAGER': 'Command Center Manager', 'ROLE_DEV': 'Command Center Developer', 'ROLE_TRANSLATOR': 'Command Center Translator']

   // idp configuration
   grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'
   grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'
   grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']

   // sp configuration
   grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"
   grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"
   grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';
   grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'

   // true if want token to auto renew when user logs into server
   grails.plugin.springsecurity.saml.autoRenewToken = true

   // specify number of days until token expires
   grails.plugin.springsecurity.saml.renewTokenDays = 90

Extra Configuration for Https

If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https. For example: 

<Connector port="8080" 
           protocol="HTTP/1.1"
           ...
           scheme="https"
/>

Trouble-Shooting your SSO Configuration

If you are having difficulty logging in to your SSO-configured Globalyzer Server (login is failing, for example), configure the Globalyzer Server to write more information to the tomcat/temp/gzserver.log file during the login process. This will help in fixing your configuration.

To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add -Dlogging.config to your JAVA_OPTS in your enterprise.sh/bat script to use this file.

For example, the modified enterprise.bat would look like this:

set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"

Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.

Note, if you are running Tomcat as a service rather than starting/stopping using the enterprise script, then update your JAVA_OPTS environment variable on the Server machine and then restart the Tomcat service.

What Differences Will I see Using SSO?

When an SSO server has been successfully configured and launched, you will see these changes.

Server changes:

  • On server login screen, an SSO login button displays, rather than Email and Password
  • On server login screen, Forgot Password link is removed
  • Admin users can no longer create other Admins, Managers, or Members
  • Manager users can no longer create other Managers or Members
  • No users can edit their profile
  • When an SSO user initially logs in to the server, a server account will be created if they were authenticated by the Identity Provider and authorized (by belonging to one of the three Globalyzer groups)
  • If user is NOT authenticated or authorized, login will fail
  • On subsequent logins, the user's server account is updated with the latest information from the Identity Provider, EXCEPT for their level of access. If they were authorized to be a Globalyzer Manager when their account was created, they will always be a Globalyzer Manager. An existing Manager account will not be switched to a Member account or an Admin account, for example. The Manager account can be deleted from the Globalyzer server (by another Manager or Admin), and then on login, the account will be recreated at the current access level as configured in the Identity Provider.

Client Workbench changes:

  • Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an SSO-configured server, a message displays saying that the password cannot be retrieved from an SSO-configured server

Client access to an SSO-configured Server:

  • To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the download Globalyzer Client here link at the bottom of the home screen) and use your email address as the username and the token as the password when connecting to the server.
  • Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.
  • Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.
  • Attempting to log in with expired tokens will fail.
Retrieved from "http://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&oldid=97559"