http://wiki.lingoport.com/api.php?action=feedcontributions&user=MaryH&feedformat=atomLingoport Wiki - User contributions [en]2024-03-28T14:46:30ZUser contributionsMediaWiki 1.31.16http://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=98223Command Center SSO Installation2024-01-25T20:18:27Z<p>MaryH: /* Trouble-Shooting your SSO Configuration */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
<b>NOTE: Indivuals should not be assigned to the Okta application. Groups should be assigned to the Okta application, and individuals should be assigned to the appropriate group!</b><br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.xml file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.xml"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=98222Command Center SSO Installation2024-01-25T20:17:53Z<p>MaryH: /* Trouble-Shooting your SSO Configuration */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
<b>NOTE: Indivuals should not be assigned to the Okta application. Groups should be assigned to the Okta application, and individuals should be assigned to the appropriate group!</b><br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.xml"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=98221Command Center SSO Installation2024-01-25T20:16:48Z<p>MaryH: /* Configure saml_configuration.conf */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
<b>NOTE: Indivuals should not be assigned to the Okta application. Groups should be assigned to the Okta application, and individuals should be assigned to the appropriate group!</b><br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97871Command Center SSO Installation2023-09-12T16:51:10Z<p>MaryH: /* Create Command Center Groups/People */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
<b>NOTE: Indivuals should not be assigned to the Okta application. Groups should be assigned to the Okta application, and individuals should be assigned to the appropriate group!</b><br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97870Command Center SSO Installation2023-09-12T16:50:45Z<p>MaryH: /* Create Command Center Groups/People */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
NOTE: Indivuals should not be assigned to the Okta application. Groups should be assigned to the Okta application, and individuals should be assigned to the appropriate group!<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97720Command Center SSO Installation2023-09-01T15:09:33Z<p>MaryH: /* Configure saml_configuration.conf */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Command Center and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:" + samlpath + "/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:' + samlpath + '/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'file:' + samlpath+'/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = samlpath + "/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97709Globalyzer Server SSO Installation2023-08-31T22:19:05Z<p>MaryH: /* Configure GzserverConfig.groovy */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [<your-saml-key>:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97708Command Center SSO Installation2023-08-31T22:18:06Z<p>MaryH: /* Configure saml_configuration.conf */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files under <userHomeDirectory>/Lingoport_Data/saml on the machine running the Command Center Server. Create that directory if not there.<br />
* Under <userHomeDirectory>/Lingoport_Data/saml, add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:<userHomeDirectory>/Lingoport_Data/saml/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = '<entity id found in idp.xml>'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:<userHomeDirectory>/Lingoport_Data/saml/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "<userHomeDirectory>/Lingoport_Data/saml/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "<entity id found in sp.xml file>"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = '<entity id found in sp.xml file>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = '<entity id found in sp.xml file>'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97600Globalyzer Server SSO Installation2023-08-24T18:13:12Z<p>MaryH: /* Extra Configuration for Https */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [<your-saml-key>:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97599Command Center SSO Installation2023-08-24T18:08:10Z<p>MaryH: /* Extra Configuration for Https */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can configure your reverse proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97598Command Center SSO Installation2023-08-24T18:00:38Z<p>MaryH: /* Extra Configuration for Https */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can tell your proxy to preserve https in the request header. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97597Command Center SSO Installation2023-08-24T17:58:30Z<p>MaryH: /* Extra Configuration for Https */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
<br />
Or you can set this configuration where you set your proxy. In apache, it would look like this:<br />
RequestHeader add X-Forwarded-Proto https<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97596Command Center SSO Installation2023-08-22T22:38:35Z<p>MaryH: /* Trouble-Shooting your SSO Configuration */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97595Command Center SSO Installation2023-08-22T22:38:04Z<p>MaryH: /* Trouble-Shooting your SSO Configuration */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
<br />
To do this, place a special logback.groovy file (provided by Lingoport) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS environment variable.<br />
<br />
<br />
For example:<br />
<br />
<code>JAVA_OPTS=-Xms256m -Xmx1600m -Dlogging.config=/path/to/logback.groovy"</code><br />
<br />
Then stop and start your Command Center Server to incorporate the changes. You should now see more information written to the ccserver.log file.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97569Command Center SSO Installation2023-07-27T16:15:01Z<p>MaryH: /* What Differences Will I see Using SSO? */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other users, except for API users<br />
* 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 four Command Center groups)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97568Command Center SSO Installation2023-07-27T16:11:03Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Replace cc.saml.lingoport.io with your machine name<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97567Command Center SSO Installation2023-07-27T16:09:55Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Commend Center Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings<br />
* Replace <your-saml-key> with the key name you chose above<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97566Command Center SSO Installation2023-07-27T16:08:14Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Commend Center Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97565Command Center SSO Installation2023-07-27T16:07:36Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://cc.saml.lingoport.io/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://cc.saml.lingoport.io/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Commend Center Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97564Command Center SSO Installation2023-07-27T16:06:45Z<p>MaryH: /* Configure the Identity Provider */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://cc.saml.lingoport.io/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Commend Center Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97563Command Center SSO Installation2023-07-27T16:05:28Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Commend Center Server is running on ... keeping the /command-center/login/saml2/sso/<your-saml-key> or /command-center/saml/SingleLogout endings<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Command_Center_SSO_Installation&diff=97562Command Center SSO Installation2023-07-27T16:01:25Z<p>MaryH: /* Create Okta Application */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Command Center with SAML SSO, first, the Identity Provider must be configured to allow access to Command Center.<br />
Then, Command Center must be configured for SSO. The result is three key files referenced from saml_configuration.conf<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Command Center application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Command Center Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Command Center Admin</b> group<br />
* Create <b>Command Center Manager</b> group<br />
* Create <b>Command Center Developer</b> group<br />
* Create <b>Command Center Translator</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Command Center Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/command-center/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/command-center/login/saml2/sso/cckey<br />
* Audience URI: <your server machine>/command-center/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/command-center/saml2/service-provider-metadata/cckey<br />
* Attributes Section: enter in the following:<br />
Email, Unspecified, user.email<br />
Username, Unspecified , user.login<br />
Last Name, Unspecified , user.lastName<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Command Center<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the four Command Center groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/command-center/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/command-center/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/command-center/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/command-center/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> 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<br />
<br />
== Configure saml_configuration.conf ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Command Center Server.<br />
* Add and configure the following lines to saml_configuration.conf:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
commandcenter.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Username', 'email': 'Email', 'fullname' : 'Last Name']<br />
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']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
If you are having difficulty logging in to your SSO-configured Command Center Server (login is failing, for example), configure the Command Center Server to write more information to the tomcat/temp/ccserver.log file during the login process. This will help in fixing your configuration.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Translators<br />
* Manager users can no longer create other Managers or Translators<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97124Globalyzer Server SSO Installation2023-03-07T18:45:00Z<p>MaryH: /* Extra Configuration for Https */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [<your-saml-key>:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector to https.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97123Globalyzer Server SSO Installation2023-03-07T18:44:27Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [<your-saml-key>:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Extra Configuration for Https ==<br />
If your server is running under https, in the tomcat server.xml file, you must set the scheme for the Connector.<br />
For example:<br />
<Connector port="8080" <br />
protocol="HTTP/1.1"<br />
...<br />
scheme="https"<br />
/><br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97122Globalyzer Server SSO Installation2023-03-07T18:21:15Z<p>MaryH: /* Encrypting SSO Passwords */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [<your-saml-key>:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97121Globalyzer Server SSO Installation2023-03-07T18:20:44Z<p>MaryH: /* Configure GzserverConfig.groovy */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy <your-key-store.jks>, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/<your-key-store.jks>"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = '<your-keystore-pw>'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'<your-keystore-pw>']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97120Globalyzer Server SSO Installation2023-03-07T18:17:12Z<p>MaryH: /* Generate Keys and Keystore */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore <your-key-store.jks><br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore <your-key-store.jks> -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// if https, configure the following<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97119Globalyzer Server SSO Installation2023-03-07T18:16:01Z<p>MaryH: /* Configure GzserverConfig.groovy */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
grails.plugin.springsecurity.saml.loginFormUrl = '/saml2/authenticate/<your-saml-key>'<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [<your-saml-key>:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = '<your-saml-key>'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = '<your-saml-key>'<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = 'file:/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['<your-saml-key>':'file:/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// if https, configure the following<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97118Globalyzer Server SSO Installation2023-03-07T17:53:36Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/<your-saml-key>"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/<your-saml-key>" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97117Globalyzer Server SSO Installation2023-03-07T16:22:05Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app, relacing gzkey with the key you created above.<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97114Globalyzer Server SSO Installation2023-03-07T16:20:50Z<p>MaryH: /* Generate Keys and Keystore */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias <your-saml-key> -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97113Globalyzer Server SSO Installation2023-03-07T16:20:34Z<p>MaryH: /* Generate Keys and Keystore */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias Myour-saml-key> -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97110Globalyzer Server SSO Installation2023-03-07T16:19:52Z<p>MaryH: /* Create Okta Application */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<your-saml-key>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<your-saml-key>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias gzkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97109Globalyzer Server SSO Installation2023-03-07T16:19:05Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<samlkey>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<samlkey>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias gzkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/login/saml2/sso/<your-saml-key> or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97107Globalyzer Server SSO Installation2023-03-07T16:17:55Z<p>MaryH: /* Generate sp.xml */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<samlkey>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<samlkey>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias gzkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97105Globalyzer Server SSO Installation2023-03-07T16:14:10Z<p>MaryH: /* Generate Keys and Keystore */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<samlkey>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<samlkey>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias gzkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=97103Globalyzer Server SSO Installation2023-03-07T16:12:45Z<p>MaryH: /* Create Okta Application */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/login/saml2/sso/<samlkey>, for example https://saml.lingoport.net/gzserver/login/saml2/sso/gzkey<br />
* Audience URI: <your server machine>/gzserver/saml2/service-provider-metadata/<samlkey>, for example https://saml.lingoport.net/gzserver/saml2/service-provider-metadata/gzkey<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Release_Notes&diff=96977Globalyzer Release Notes2023-01-27T22:36:42Z<p>MaryH: /* Globalyzer 6.8.0 Release Notes (March 2023) */</p>
<hr />
<div>For supported versions, please see:<br />
[[Lingoport_Suite_Installation#Supported_Versions]]<br />
<br />
==Globalyzer 6.8.0 Release Notes (February 2023)==<br />
The 6.8.0 release includes the following new features:<br />
<p><br />
<ul><br />
<li><b>Support for SAML/SSO</b>:<br />
The Globalyzer Server can now be configured with SAML/SSO, in addition to LDAP.<br />
This allows seamless integration with third party identify providers.<br />
</li><br />
<li><b>Support for Command Center</b>:<br />
Command Center is a new Lingoport product that communicates with the Globalyzer Server. For information on Command Center, please see: [[Command_Center_Pages | Command Center]]<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.7.0 release==<br />
<p><br />
<ul><br />
<li><b>Requires JDK11 to run the Globalyzer Client</b>:<br />
You can download from OpenLogic https://www.openlogic.com/openjdk-downloads<br />
</li><br />
<li><b>Password Encryption Changed</b>:<br />
You will be prompted to log in the first time after installing the Workbench.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.6.0 release==<br />
<p><br />
<ul><br />
<li><b>Go Rule Set:</b><br />
Globalyzer now provides a Go rule set to scan Go language code, and supports Go string externalization to json resource files.<br />
</li><br />
<li><b>Locale-Sensitive Method Priority Updates for JavaScript and CSharp Rule Sets:</b><br />
To streamline your internationalization work, we have updated the default priority settings for JavaScript and C# locale-sensitive methods, setting the methods that are most likely to be issues, to priority 1 or 2.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.5.0 release==<br />
<p><br />
<ul><br />
<li><b>Python Rule Set:</b><br />
Globalyzer now provides a python3 rule set to scan python code, and supports python string externalization to either po or properties resource files.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.4.1 release==<br />
The 6.4.1 release involves the Globalyzer Client only (not the Globalyzer Server). This release provides the following enhancements, along with minor bug fixes:<br />
<ul><br />
<li><b>Compressed Prediction Report:</b><br />
The [[ Machine_Learning#Prediction_Reports | prediction report]] for a scan can become quite large. <br />
The generated report is now a zip file, making it easier to check in to version control.<br />
</li><br />
<li><b>Improved Scanning of jsx Files:</b><br />
Jsx files are a mixture of JavaScript and HTML. They are now scanned, by default, by both our JavaScript and HTML rule sets. <br />
Also, HTML scanning of these files has been greatly improved.<br />
</li><br />
<li><b>Improved Scanning of TypeScript Files:</b><br />
The JavaScript rule set has been enhanced to scan ts files. Tsx files (a mixture of TypeScript and HTML), are also scanned by default by both JavaScript and HTML rule sets.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.4.0 release==<br />
<p><br />
<ul><br />
<li><b>Method Statement Filters:</b><br />
These new filters are similar to Method Line Filters, except they apply to a programming language statement, as opposed to a line of code.<br />
If Globalyzer detects a Locale-Sensitive Method, and within the same statement finds a Method Statement Filter,<br />
that method will be excluded from the Locale-Sensitive Method Scan Results.<br />
</li><br />
<li><b>Modified order of Embedded String Filtering and Retention Rules:</b><br />
Prior to this release, the Embedded String scan would first find all strings, then apply all Filtering rules, followed by all Retention rules. <br />
We have found that interleaving Filtering and Retention rules generates better results.<br />
We now apply specific filters and patterns before more general filters and patterns. <br />
For example, a string might be a parameter to a method that is in a line that is part of a statement.<br />
So, if you defined a String Method Pattern to retain an issue, but you have a String Statement Filter that <br />
filters the statement, the issue will ultimately be filtered since the more general, String Statement Filter, is applied last. <br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.0 release==<br />
<ul><br />
<li><b>Concatenation Detection for HTML Strings:</b><br />
HTML strings are sometimes a combination of text, externalized text, server-side code, and in the case of .vm files, variables.<br />
Globalyzer now detects these combinations and will set the priority to C. <br />
Globalyzer also provides a new rule retention for HTML rule sets only, called <b>String Concatenation Patterns</b>,<br />
to find concatenations that would normally be Filtered.<br />
For example, an HTML string which is a series of string externalizations<br />
would not be Active (since the string does not contain text to externalize). <br />
However the string should most likely be externalized as a whole, instead of concatenated parts. <br />
Use a String Concatenation Pattern to find these situations so they can be dealt with properly.<br />
</li><br />
<li><b>Focus on Top Scan Result Issues:</b><br />
Globalyzer has taken a number of steps to help users focus on top issues.<br />
<ol><br />
<li><br />
Defined Scan Views for <b>Top</b>, <b>Most</b>, and <b>All</b> Predicted Issues (select Scan->Refresh Default Scan Views to update existing projects)<br />
</li><br />
<li><br />
Provided shortcut keys to quickly switch among the three views. Ctrl+Shift+1 for Top, Ctrl+Shift+2 for Most, Ctrl+Shift+3 for All.<br />
</li><br />
<li><br />
Provided a new Lite attribute, <b>report-priorities</b>, to specify the priorities to include in the generated report.<br />
</li><br />
</ol><br />
</li><br />
<li><b>Password Encryption for Enterprise Servers:</b><br />
Companies with their own Globalyzer Server must provide some configuration information in the GzserverConfig.groovy file.<br />
This information includes some passwords: the database user password and, if the server is configured to use LDAP, an LDAP password.<br />
These passwords may now be encrypted via a new utility: <b>globalyzer-encrypt-password.jar</b> and the encrypted password may be specified in the<br />
GzserverConfig.groovy file.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.2.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.2 release==<br />
<ul><br />
<li><b>Import Lite Project Definition Files:</b><br />
The Workbench can now import Lite Project Definition files, reading from the file to create<br />
a project with scans in the Workbench.<br />
Also, if you are creating an Eclipse project and the base path of the project contains a lingoport/LiteProjectDefinition.xml file, <br />
you may choose to automatically import the file. <br />
In this way you can quickly point to a repo and create the Workbench project from the Lite file in the repo.<br />
</li><br />
<li><b>Support for Android String Externalization:</b><br />
Globalyzer now supports a new resource type, named android, available for both Java and XML scans.<br />
Externalizing to the android resource file writes strings to the file: strings.xml.<br />
</li><br />
<li><b>Rule Set Comparison from the Workbench:</b><br />
From the Workbench, you may now select two rule sets and generate a report comparing them. Previously, this feature was only available from our Command Line Interface.<br />
For example, you can create a default rule set and then extend it, adding/deleting/modifying rules. To see the differences, compare the base rule set with your modified rule set.<br />
</li><br />
<li><b>String Statement Filters for most Rule Set Languages:</b><br />
Originally, String Statement Filters were only implemented for JavaScript. Now, they are available for all languages that support the notion of statements; for example: Java, C#, C++, etc.<br />
If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
</li><br />
<li><b>Improvements regarding Temporary Rules:</b><br />
In the Workbench, you can create temporary rules and scan with them without adding them to rule sets. You may<br />
now see these temporary rules across projects and choose to either delete or submit them. Select Project->Show/Submit Rule Set Filters/Detections menu item in the Workbench.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and provides the following new features:<br />
</p><br />
<ul><br />
<li><b>Introducing Prediction Reports:</b><br />
Prediction Reports are used to save prediction markings, one report per scan. <br />
After marking the predictions for a scan, choose <b>Machine Learning->Export Prediction Report</b> to generate a scan's Prediction Report. <br />
These reports can then be shared with <br />
Globalyzer Lite, other Workbenches, and be reflected in the Dashboard. <br />
Globalyzer Lite will automatically apply the Prediction Report after scanning; <br />
other Workbenches can import the Prediction Report to update their Scan Results with the latest markings; <br />
and the Dashboard, which relies on Globalyzer Lite, will now display the same Scan Results and <br />
predictions shown in the Workbench.<br />
Remember that to speed up your i18n analysis, use <b>Machine Learning->GO!</b> It will use your T/F predictions to make additional predictions.<br />
</li><br />
<li><b>Set Prediction column rather than ToDo, Invalid, and Ignore Status:</b><br><br />
We are deprecating the use of <b>ToDo</b>, <b>Invalid</b>, and <b>Ignore</b> status in favor of<br />
marking the prediction of an issue T/F/P. <br />
<ul><br />
<li>Rather than changing the status of an issue to ToDo, set the prediction to T.</li><br />
<li>Rather than changing the status of an issue to Invalid, set the prediction to F.</li><br />
<li>Rather than changing the status of an issue to Ignore, set the prediction to P (for pending).</li><br />
</ul><br />
After marking your predictions, choose <b>Machine Learning->Export Prediction Report</b><br />
so that your new predictions will be reflected in the Dashboard and can be shared with other<br />
Workbenches.<br />
</li><br />
<li><b>Dashboard False Positive Changes:</b><br />
In our 6.0 release, we added support for synchronizing false positive issues between the <br />
Dashboard and the Workbench using a DFP status.<br />
We are deprecating the DFP status in favor of a DFP prediction value.<br />
Now, <b>Reload Dashboard False Positives</b> will set the prediction value for all<br />
the False Positives on the Dashboard to DFP in the Workbench. Issues with a DFP prediction value can be ignored.<br />
Also, it is no longer necessary to <b>Update to Dashboard as False Positive</b>. Simply mark the prediction F<br />
and export the Prediction Report. Issues marked F will not be displayed on the Dashboard.<br />
To clear a DFP, go to the issue on the Dashboard and make it active again.<br />
</li><br />
<li><b>New Scan Views:</b><br />
We added the following default Scan Views to easily view active issues with various prediction values:<br />
<ul><br />
<li>All Scan Issues - All issues found by scanning, regardless of prediction value</li><br />
<li>All Predicted Active - All issues except those that you, GO!, or the Dashboard<br />
set to False (F, ML False, DFP). These issues are reflected in the Workbench Scan Summary and<br />
in the Dashboard.</li><br />
<li>All Working Active - All issues except those that you have explicitly set to F, or that the<br />
Dashboard set to DFP. Use <b>GO!</b> to speed up the evaluation process.</li><br />
<li>All Undecided - All issues without a set prediction value of T/F/P/DFP.<br />
These are the issues that you still need to evaluate.</li><br />
<li>Prediction T - All active issues with prediction marked T</li><br />
<li>Prediction F - All active issues with prediction marked F</li><br />
<li>Prediction P - All active issues with prediction marked P (pending)</li><br />
<li>Prediction DFP - All active issues with prediction marked DFP</li><br />
</ul><br />
</li><br />
<li><b>Sharing GO! Results:</b><br />
In the Workbench, you automatically generate Machine Learning and<br />
Prediction Report files for a scan <br />
by selecting <b>Machine Learning->GO!</b><br />
These predictions can then be shared with other Workbenches and reflected in the Dashboard.<br />
If you would like to apply existing Machine Learning files to your Scan Results,<br />
you can select <b>Machine Learning->Import Machine Learning</b>. Run <b>GO!</b> whenever you<br />
add or modify T/F/P predictions, so that GO! can make more predictions that are then saved in the<br />
Machine Learning and Prediction Report files.<br />
</li><br />
<li><b>Globalyzer Command Line Client and Machine Learning:</b><br />
When running a scan via the Globalyzer Command Line Client (CLI), you can now apply existing Machine Learning files via a new <b>--machine-learning</b> flag. New code will then be predicted. Note, you still must generate the Machine Learning files for a scan via the Workbench's <b>Machine Learning->GO!</b><br />
</li><br />
<li><b>Scan Reports and Prediction Value:</b><br />
By default, all reports generated from the Workbench, CLI, and Lite will contain only Predicted Active results. This means that results with a prediction value of F, ML False, or DFP will not be reported. XML reports generated from Lite are the exception, and contain results for all prediction values. In the Workbench, you can now configure detailed reports to contain desired prediction values.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1 release==<br />
* '''Introducing Machine Learning''': Machine Learning is a powerful new feature that helps users more quickly identify the real issues in their source code. After scanning with Rule Sets in the Workbench, the user marks some active issues as TRUE or FALSE and then invokes Machine Learning to make predictions on the remaining active issues. It may predict ML True (a real issue), ML False (a false issue), or ML NULL (not enough information to make a prediction). This is an iterative process; the user can make corrections by marking more predictions as TRUE or FALSE and re-invoking Machine Learning, until the prediction results are satisfactory. At this point, the issues predicted as TRUE, ML True, or ML NULL are the ones to address. <br />
* '''Company Dictionary''': This feature allows users to add words to their Globalyzer Company's dictionary when scanning. A Company Dictionary is maintained on the Globalyzer Server. Users can upload, download, and view their dictionary contents. To add words to the dictionary, download the dictionary from the Server, modify the dictionary file on your local machine, and upload to the Server. Note that there is one Company Dictionary per company, so all users within the company will see the same dictionary contents. To use the Company Dictionary, download the dictionary from the server and place in your Lingoport directory. When scanning, Globalyzer will include the words from your downloaded dictionary file along with those in the Lingoport Dictionary. <br />
* '''Import Rule Set Enhancement''': You can now export all your rule sets to a single Rule Set Repository file. And then, when importing from this file, you can select just a subset of the Rule Sets to import. <br />
* '''Updated Rule Terminology''': We changed some of our Globalyzer Rule names to be clearer and more consistent: <br />
** String Literal Filters are now String Content Filters<br />
** String Retention Patterns are now String Content Patterns<br />
** String Operand Filters are now String Variable Filters<br />
** String Operand Patterns are now String Variable Patterns<br />
* '''Globalyzer Server requires Tomcat 8.5.x''': The 6.1 release of the Globalyzer Server has been upgraded to use Grails 3, which requires Tomcat 8.5.x (for our Enterprise users).<br />
<br />
==The following lists new features in the Globalyzer 6.0 release==<br />
* '''Support for Local Rule Sets using Lite''': This feature allows scanning to occur without accessing the Globalyzer Server. Rule sets are stored in local files, rather than retrieved from the Server. Use of this feature requires a Globalyzer License to be downloaded from the Server and stored on your local machine. Also note that this feature is only available for Globalyzer Lite. The Workbench, for example, still requires a connection to the Globalyzer Server.<br />
* '''Dashboard False Positive''': A new status has been implemented for Globalyzer, called Dashboard False Positive, or DFP. This status allows the false positives manually ignored in the Workbench (via status changes) to be reflected on the Dashboard. When an issue is set to DFP, the Dashboard is updated and the issue is ignored. The Workbench can also update its list of DFP issues from the Dashboard, allowing the Workbench to ignore false positives found and set by other developers.<br />
* '''Lite Jenkins Plugin''': On-boarding a Globalyzer Lite Jenkins job is made easy by the new Jenkins Plugins.<br />
* '''Security Enhancements''': Several security enhancements have been implemented for the Globalyzer Server. Our password encryption algorithm has been upgraded to use bcrypt, forgot password now performs a password reset rather than retrieval, and we now guard against clickjacking and directory/path traversal attacks. Our version of Tomcat has been upgraded to enable some of these security features.<br />
* '''Report Enhancements''': Previously, generating reports from the Workbench only included issues with Active or Todo status. Now, you can choose the statuses of interest, generating a report of Filtered issues, for instance.<br />
<br />
==The following lists new features in the Globalyzer 5.4 release==<br />
* '''Support for 4-byte UTF-8 Characters''': Updates the MySQL database used by the Globalyzer Server (and the Globalyzer Workbench if installed to use MySQL) to accept 4-byte characters, such as 𡇙. Previously, only supported up to 3-byte UTF-8 characters. Note that your MySQL version must be 5.5.3 or later and MySQL variable settings must be updated to utf8mb4. Instructions are available in Server upgrade documentation as well as Client download and installation directions.<br />
* '''Introducing json as a resource type for JavaScript''': JavaScript embedded strings can now be externalized to json files.<br />
<br />
==The following lists new features in the Globalyzer 5.3 release==<br />
<p><br />
<ul><br />
<li><b>Introducing the Swift Rule Set:</b><br />
We added a new Rule Set to support the Swift programming language. It contains rules for<br />
Embedded Strings, Locale-Sensitive Methods, Static File References, and General Patterns.<br />
</li><br />
<li><b>Enhanced Perl Rule Set:</b><br />
In release 5.2, we added support for Perl Locale-Sensitive Methods, but no content. In this release, <br />
we provide Locale-Sensitive Methods and their corresponding help, in addition to new rules in other categories.<br />
</li><br />
<li><b>Introducing the Globalyzer MVN Plugin:</b><br />
MVN projects can be scanned using our Globalyzer MVN plugin. <br />
The Globalyzer MVN plugin scans your MVN project and generates scan reports to a directory <br />
specified in the pom.xml file. <br />
We ask our MVN customers to install the MVN plugin in a <br />
private MVN repository for your company. Once installed, all developers<br />
can then access the plugin to scan their code.<br />
</li><br />
</ul><br />
</p><br />
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Note:</b> As of 5.3, all Globalyzer Clients are compiled with <b>Java 8</b>;<br />
to run a client, you must have <b>Java 8 (or later)</b> installed on your machine.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 5.2.1 release ==<br />
This release provides an update to the '''Globalyzer Workbench''' (5.2.1): It is now based on '''Eclipse version 4.6''' (Neon) which runs on '''Java 8'''. The previous version of the Workbench (5.2.0) was based on Eclipse 3.7 and is now deprecated. Workbench 5.2.0 is kept for those clients with previous version of Java, like Java 7. However, we strongly recommend using Workbench 5.2.1 and Java 8.<br />
<br />
==The following lists new features in the Globalyzer 5.2 release==<br />
* '''Introducing Rule Categories''': Rules now have a new Category attribute that allows rules across the rule set to be grouped. Rules can then be quickly enabled/disabled according to category from the Edit Rule Set page.<br />
* '''Enhanced JavaScript Rule Set''' includes jQuery, AngularJS, ReactJS, and NodeJS specific rules: These new rules use the Category attribute to identify the JavaScript library associated with the rule. From the Edit Rule Set page, enable or disable rules for the JavaScript Library Categories to more effectively scan your code. New detection and filter rules have been added to scan code that uses<br />
**'''jQuery'''<br />
**'''AngularJS'''<br />
**'''ReactJS'''<br />
**and '''NodeJS''' libraries.<br />
*New Filter Type for JavaScript Rule Sets - '''String Statement Filters''': If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
*Support for '''HTML Tag Libraries''': Globalyzer now supports skipping Tag Library tags during its HTML Embedded String scan, resulting in cleaner scan results. The Tag Library tags are configured in the Ignored HTML Tags rules.<br />
*Locale-Sensitive Method Support for the '''Perl Rule Set''': You can now configure Locale-Sensitive Methods for Perl Rule Sets.<br />
*Support for Mason Files: Globalyzer can now scan Mason Files, which are files containing JavaScript, HTML, and Perl.<br />
<br />
==The following lists new features in the Globalyzer 5.1 release ==<br />
*'''Finer control configuring Locale-Sensitive Methods for Java:''' There are two new fields when configuring Locale-Sensitive Methods for Java, Class or Variable Type and Parameter Type(s) to Filter. If the Class or Variable Type is specified, then only method calls for this class will be detected. If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method will not be detected. <br />
**For example, you can now configure ''toLowerCase'' to be detected only when called via the ''java.lang.String'' class only if a ''java.util.Locale'' parameter has not been provided.<br />
*'''Globalyzer Lite and API Enhancements''': Globalyzer Lite and the API now support setting session and scan options, similar to what is already available in the Globalyzer Workbench. These new options include: <br />
**the location of the data dictionary<br />
**whether or not to filter results against the dictionary<br />
**the scan timeout duration, source file encoding, result types to scan<br />
**comment text.<br />
*'''Globalyzer Lite Login Feature''': You can now set default login information for Globalyzer Lite by creating a '''.globalyzerrc''' file. When processing Project Definition Files, Lite will grab the username/password information from the .globalyzerrc file if it is not provided in the Project Definition File itself.<br />
For more detailed information on 5.1 features, please go to [[Globalyzer 5.1 Features|Globalyzer 5.1 Features]]<br />
<br />
==The following lists new features in the Globalyzer 5.0 release ==<br />
<br />
*'''String Concatenation Detection''': Globalyzer now flags string literals that are part of string concatenations, helping you to easily identify and refactor the concatenation before externalizing strings to resource files. As Globalyzer scans your source code, it sets a detected string's Scan Results priority to the new string concatenation priority 'C' when at least one of the following conditions are true:<br />
**string literal starts or ends with white space<br />
**string literal is preceded or followed by (language specific) concatenation characters<br />
**string literal is a parameter to a Locale-Sensitive Method configured to have priority 0 (the string concatenation priority)<br />
** See [[Globalyzer Concatenation]]<br />
*Finer control when configuring '''String Method Filters and String Method Patterns''' for Java: When configuring String Method Filters and String Method Patterns for your Java Rule Set, you can now optionally include Class or Variable Type(s) to give you finer control over issues being filtered/detected. For example, rather than filtering all strings passed to the method, setName, you can associate a Class name so filtering will only take place when the embedded string is passed to the setName method of the specified Class.<br />
** See [[Globalyzer 5 Java_Rules]]<br />
*Globalyzer Lite Project Definition File '''Generation from Workbench''': Save time setting up Globalyzer Lite by generating your Globalyzer Lite Project Definition File from the Workbench. Create your Workbench Project and then select <code>File->Export->Globalyzer->Export Project Definition (Lite)</code>.<br />
<br />
==The following lists new features in the Globalyzer 4.8.5 release ==<br />
This release focuses on Globalyzer Lite features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports '''navigating to a candidate issue''' within an IDE by '''clicking on the issue''' in the IDE console window. The documentation covers integration within Visual Studio, IntelliJ IDEA, and Eclipse. Integration with numerous other IDEs is also possible.<br />
**'''Build Integration''': Added new command line option to specify the type of console output at the command line.<br />
<br />
==The following lists new features in the Globalyzer 4.8.3 release ==<br />
This release includes bug fixes and these features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports finding and correcting internationalization issues entirely within an IDE. Our documentation covers integration within '''Visual Studio, IntelliJ IDEA, and Eclipse'''. Integration with numerous '''other IDEs''' is also possible.<br />
**'''Build Integration''': Added new command line options. The project location, scan items, and report directory can now be easily specified at runtime.<br />
<br />
* '''Enhanced Configuration Options''' for Enterprise Servers: <br />
**Enterprise Servers can now configure information and links that display on the Login screen, as well as messages that display for LDAP-configured servers. <br />
**In addition, a default team name may be configured; if specified, newly created users will automatically be assigned to the default team.<br />
<br />
==The following lists new features in the Globalyzer 4.8 release==<br />
<br />
*Introducing '''Globalyzer Lite''': Globalyzer Lite is a lightweight version of the Globalyzer Client. <br />
** It is smaller and faster to install than the Globalyzer Workbench and CLI.<br />
** It requires no external database. <br />
** A '''Project Definition XML''' file allows for the creation of temporary projects and scans, execution of those scans, and generation of corresponding reports. This can be particularly useful in a Continuous Integration model. <br />
** Multiple projects can be processed simultaneously on the same machine.<br />
** '''Note''': This feature requires special licensing. Please contact sales@lingoport.com.<br />
*Globalyzer Server Runs on '''Java 8''': The 4.8 release upgrades the Globalyzer server to run on Java 1.8 (for our Enterprise users). <br />
<br />
'''Note''': Tomcat 7 is now required for deploying the 4.8 Globalyzer Server.<br />
<br />
==The following lists new features in the Globalyzer 4.7 release==<br />
<br />
'''Note''': As of the 4.6 Release, Globalyzer requires Java 1.7. Please make sure that JDK 1.7 is installed on your machine before attempting to install the Globalyzer Client.<br />
<br />
*'''The Globalyzer API''': The Globalyzer API allows you to create Globalyzer projects and scans, execute scans, and generate reports from a java program. This enables projects to be created "on the fly." For example, during code check-in, the check-in process could trigger the execution of a java program that calls the API to scan the source code, enabling timely feedback on its internationalization status. See the Globalyzer API reference page for more information on how to use this new feature.<br />
*'''LDAP for Enterprise Servers''': The Globalyzer Server can be configured to use your company's LDAP system. All Globalyzer user access and information is then managed by LDAP. '''Note''': This feature requires ''special licensing''. Please contact sales@lingoport.com.<br />
*'''Improved Rule Sets''': Updated Globalyzer default rule sets, with specific attention on JavaScript and Objective-C.<br />
<br />
Should you encounter problems or have questions, please email ''support@lingoport.com''.<br />
<br />
==The following lists new features in the Globalyzer 4.6 release==<br />
<br />
*'''Introducing String Operand Filters/Patterns''': This feature (available for all languages except HTML) allows you to filter/retain string literals that are compared with, or assigned to, variables. For languages such as XML, you can use this to filter out string attributes.<br />
*'''Filter Strings used as Array Indices for C#, PHP, and JavaScript''': C#, PHP, and JavaScript support Associative Arrays, where strings can be used to index arrays. String literals used in this manner are not user-facing and should be filtered. This filtering is now performed automatically; there is no Rule Set configuration work required. Note that this has only been implemented for C#, PHP, and JavaScript.<br />
*'''Managers can Assign Ownership of Rule Sets''': Prior to this feature, only Rule Set owners could assign their Rule Sets to another user within the company. Now, managers can assign Rule Sets of team members to other users within the company.<br />
*'''Email False Positive Scan Results to Lingoport''': Feedback from Globalyzer users regarding false positive Scan Results has been invaluable. To help facilitate this feedback, the Workbench now allows the user to select entries in Scan Results and email them to Lingoport via a menu selection. This information will help us further refine our default Rule Sets.<br />
*'''Improved JavaScript Rule Set''': New filters have been added to the JavaScript Rule Set and help for JavaScript Locale-Sensitive Methods has been enhanced.<br />
*'''Secure HTTP''': Globalyzer now supports the additional security of HTTPS for all data that passes between the Client and the globalyzer.com Server.<br />
*'''New version command for the Command Line Client''': The Globalyzer Command Line Client now supports --version and -ver to provide version information for both the Client and the Server.<br />
*'''String Method Filters/Patterns now filter/retain Strings within Nested Methods''': If string literals are passed to a nested method, they will be filtered if the outer method is a String Method Filter, and retained if the outer method is a String Method Pattern.<br />
*'''Reason Field in Scan Results more Descriptive for Embedded Strings''': In addition to displaying the pattern of the rule (that either filtered or retained the Embedded String), the Reason field now includes "Literal", "Line", "Method", or "Operand", to indicate the type of the rule.<br />
*'''Reorganization of Reference Section Help''': The Reference Section Help has been organized into Command Line, Server, and Workbench Reference sections.<br />
<br />
==The following lists new features in the Globalyzer 4.5 release==<br />
<br />
*'''Rule Set Inheritance''': Rule Sets now support inheritance! A Rule Set can be created to extend an existing Rule Set. The new Rule Set inherits all the rules of the parent Rule Set and can add new rules and/or override inherited rules. This allows companies to centrally manage core Rule Sets and project teams can then inherit the modifications.<br />
*'''Comparing Rule Sets''': Available from the Command Line Interface, Rule Sets defined on the server can now be compared, generating an HTML report with the differences.<br />
*'''Support for Android''': The Java Rule Set has been enhanced to support android applications. New String Method Filters, String Literal Filters, and String Line Filters have been added to weed out false positive Embedded Strings.<br />
*'''Time Stamps in Console Output and in Show Log''': Time Stamps have been added to the Console output as well as the Show Log HTML page.<br />
*'''Updated RESX Resource File''': The generated RESX Resource File has been updated from version 1.3 to 2.0.<br />
Our '''4.3.1''' release made a few important tuning and performance improvements in the areas of MySQL Client database support, scanning, and the File Inspector.<br />
<br />
==The following lists new features in the Globalyzer 4.3 release==<br />
<br />
*'''Shared Globalyzer Projects''': Globalyzer project and scan configuration (without scan results) can now be shared. Instead of explicitly importing and exporting projects, Globalyzer manages these tasks automatically, enabling team members to work on the same project seamlessly. See the Shared Projects reference page for more information on how to use this new feature.<br />
*'''Import/Merge''': When importing a Globalyzer project that already exists in your workspace, you now have the option to either Overwrite or Merge. Overwrite deletes your existing project before importing the new one; merge combines the imported project with your existing one.<br />
*'''Globalyzer Data Directory Location''': During Client Installation, you are now prompted for the location of the Data Directory, where Globalyzer stores application data and log files as well as the optional HSQLDB database. The default is [userhome]/.globalyzer, but this can be set to another location.<br />
*'''Additional Help on Headless Globalyzer Install''': Login to the Globalyzer Server and click on the Globalyzer Client download link. The Client Installation download page includes instructions on how to install the Globalyzer Client via a script as opposed to a GUI. You'll want to use this when installing Globalyzer to build machines where Globalyzer scanning can be part of the nightly build.<br />
*'''Suggested Rule Sets for Unsupported Languages''': The Create Rule Set reference page provides Rule Set suggestions for currently unsupported languages.<br />
*'''File Inspector Report Line Counts''': Line counts have been added to File Inspector Reports.<br />
<br />
==The following lists new features in the Globalyzer 4.2 release==<br />
<br />
*'''Objective-C Rule Set''': We've added this important rule set to help you internationalize your iOS and other Objective-C applications. In addition to scanning for i18n issues in Objective-C source code, Globalyzer supports string externalization to Objective-C's preferred text resource file type: strings<br />
*'''Ability to Assign Rule Sets to Others''': Though team members can share rule sets, only the rule set owner can made modifications. This feature facilitates passing rule set ownership to another. Just edit the rule set and select a new owner in the Owner dropdown.<br />
*'''Launch Client without First Creating a Rule Set on the Server''': This feature supports the natural process of using Globalyzer: first create a Project, then run File Inspector, then create Rule Sets and Scans.<br />
*'''Create Rule Sets from the Client''': To facilitate rule set creation, Globalyzer now supports the ability to create new rule sets directly from the Client. You may still want do some customization on the Server, but it's now even easier to create that first set of rule sets as you're running the Client, creating your Globalyzer Project and looking at the results of your File Inspection report to determine which rule sets you'll need for scanning your source code.<br />
*'''Additional default Scan Views''': In addition to All Active, there are now default Scan Views for Priority 1, Priority 2, Priority 1 and 2, Ignore, Invalid, ToDo, Filtered, All, and All but Active and Filtered.<br />
*'''Notification of Newer Globalyzer Versions on Client Startup''': On Client startup, a popup displays if there is a newer version of the Client available or if there is a Client/Server version mismatch; the popup includes a link to the latest Client download.<br />
*'''Demo Results displayed based on Priority''': When a demo user executes scans, up to 100 active results are reported. This feature focuses on reporting mostly higher priority issues. It reports 50 Priority 1 issues, 30 Priority 2 issues, 20 Priority 3 issues, 5 Priority 4 issues, and 5 Priority 5 issues.<br />
<br />
==The following lists new features in the Globalyzer 4.1.1 release==<br />
<br />
*'''Additional options when pseudo-localizing your resource files''':<br />
**Pseudo-localize all your base resource files at one time by using the new '''Localize All''' button.<br />
**Use the new '''Start''' and '''End''' fields to specify characters to be displayed before and after each string. This helps you quickly identify layout issues where the full string is not fitting. For example [String]<br />
**You can also specify that each character of the string itself be replaced by an accented character for easier differentiation from English strings. For example '''Šţŕîñg'''<br />
*'''Support for Delphi RC resource file type''': The Delphi language requires its own version of the RC resource file type. Upon string externalization, a .pas file is created and updated, along with the .h and .rc files.<br />
*'''.NET Tutorial''': To accompany our Java tutorial, the .NET tutorial takes your through the basic steps involved in internationalizing a simple .NET Web application.<br />
<br />
==The following lists new features in the Globalyzer 4.1 release==<br />
<br />
*'''Refine your Rule Set from within the Client''': The Globayzer Client now allows you to create both filter and detection rules, rescan your code to see their effects, and update the Rule Set on the server when you are satisfied with the results. This Scan Result driven approach to fine-tuning your Rule Set should help you significantly streamline your scanning and filtering process.<br />
*'''Prioritize your internationalization work''': Globalyzer now prioritizes its locale-sensitive method, general pattern, and static file reference detections (in addition to embedded string detections implemented in version 3.5), helping you focus on the most likely issues first. These priority settings can be customized. You'll see the priority breakdown both on screen and in the many reports that are provided for you to track and manage your progress.<br />
*'''Retain and prioritize strings passed to specified methods''': Rule Sets now include a new detection, called String Method Patterns. This feature allows you to specifically identify methods that are passed strings that would be displayed to the end user. For example, in javascript we have added confirm, in C# Show, and in java JLabel. By identifying these types of methods and configuring them in your Rule Set, you can set the priority for these string detections and ensure that they are addressed during your internationalization process.<br />
*'''Disable Scan Feature''': Scans can now be disabled. Disabled scans can be configured but are not scanned (automatically or manually) and the scan results are not available/displayed. This feature is useful for limiting the amount of rescanning that occurs when configuring scans. The user can focus on one scan, disabling the others.<br />
*'''All resource types now support group mode''': In group mode, externalized strings are grouped by file in the resource file.<br />
*'''All resource types now support comments:''' Comments can be added to resource files and will be preserved during subsequent string externalizations.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Release_Notes&diff=96976Globalyzer Release Notes2023-01-27T22:17:27Z<p>MaryH: /* Globalyzer 6.8.0 Release Notes (March 2023) */</p>
<hr />
<div>For supported versions, please see:<br />
[[Lingoport_Suite_Installation#Supported_Versions]]<br />
<br />
==Globalyzer 6.8.0 Release Notes (March 2023)==<br />
The 6.8.0 release includes the following new features:<br />
<p><br />
<ul><br />
<li><b>Support for SAML/SSO</b>:<br />
The Globalyzer Server can now be configured with SAML/SSO, in addition to LDAP.<br />
This allows seamless integration with third party identify providers.<br />
</li><br />
<li><b>Support for Command Center</b>:<br />
Command Center is a new Lingoport product that communicates with the Globalyzer Server. For information on Command Center, please see: [[Command_Center_Pages | Command Center]]<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.7.0 release==<br />
<p><br />
<ul><br />
<li><b>Requires JDK11 to run the Globalyzer Client</b>:<br />
You can download from OpenLogic https://www.openlogic.com/openjdk-downloads<br />
</li><br />
<li><b>Password Encryption Changed</b>:<br />
You will be prompted to log in the first time after installing the Workbench.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.6.0 release==<br />
<p><br />
<ul><br />
<li><b>Go Rule Set:</b><br />
Globalyzer now provides a Go rule set to scan Go language code, and supports Go string externalization to json resource files.<br />
</li><br />
<li><b>Locale-Sensitive Method Priority Updates for JavaScript and CSharp Rule Sets:</b><br />
To streamline your internationalization work, we have updated the default priority settings for JavaScript and C# locale-sensitive methods, setting the methods that are most likely to be issues, to priority 1 or 2.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.5.0 release==<br />
<p><br />
<ul><br />
<li><b>Python Rule Set:</b><br />
Globalyzer now provides a python3 rule set to scan python code, and supports python string externalization to either po or properties resource files.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.4.1 release==<br />
The 6.4.1 release involves the Globalyzer Client only (not the Globalyzer Server). This release provides the following enhancements, along with minor bug fixes:<br />
<ul><br />
<li><b>Compressed Prediction Report:</b><br />
The [[ Machine_Learning#Prediction_Reports | prediction report]] for a scan can become quite large. <br />
The generated report is now a zip file, making it easier to check in to version control.<br />
</li><br />
<li><b>Improved Scanning of jsx Files:</b><br />
Jsx files are a mixture of JavaScript and HTML. They are now scanned, by default, by both our JavaScript and HTML rule sets. <br />
Also, HTML scanning of these files has been greatly improved.<br />
</li><br />
<li><b>Improved Scanning of TypeScript Files:</b><br />
The JavaScript rule set has been enhanced to scan ts files. Tsx files (a mixture of TypeScript and HTML), are also scanned by default by both JavaScript and HTML rule sets.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.4.0 release==<br />
<p><br />
<ul><br />
<li><b>Method Statement Filters:</b><br />
These new filters are similar to Method Line Filters, except they apply to a programming language statement, as opposed to a line of code.<br />
If Globalyzer detects a Locale-Sensitive Method, and within the same statement finds a Method Statement Filter,<br />
that method will be excluded from the Locale-Sensitive Method Scan Results.<br />
</li><br />
<li><b>Modified order of Embedded String Filtering and Retention Rules:</b><br />
Prior to this release, the Embedded String scan would first find all strings, then apply all Filtering rules, followed by all Retention rules. <br />
We have found that interleaving Filtering and Retention rules generates better results.<br />
We now apply specific filters and patterns before more general filters and patterns. <br />
For example, a string might be a parameter to a method that is in a line that is part of a statement.<br />
So, if you defined a String Method Pattern to retain an issue, but you have a String Statement Filter that <br />
filters the statement, the issue will ultimately be filtered since the more general, String Statement Filter, is applied last. <br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.0 release==<br />
<ul><br />
<li><b>Concatenation Detection for HTML Strings:</b><br />
HTML strings are sometimes a combination of text, externalized text, server-side code, and in the case of .vm files, variables.<br />
Globalyzer now detects these combinations and will set the priority to C. <br />
Globalyzer also provides a new rule retention for HTML rule sets only, called <b>String Concatenation Patterns</b>,<br />
to find concatenations that would normally be Filtered.<br />
For example, an HTML string which is a series of string externalizations<br />
would not be Active (since the string does not contain text to externalize). <br />
However the string should most likely be externalized as a whole, instead of concatenated parts. <br />
Use a String Concatenation Pattern to find these situations so they can be dealt with properly.<br />
</li><br />
<li><b>Focus on Top Scan Result Issues:</b><br />
Globalyzer has taken a number of steps to help users focus on top issues.<br />
<ol><br />
<li><br />
Defined Scan Views for <b>Top</b>, <b>Most</b>, and <b>All</b> Predicted Issues (select Scan->Refresh Default Scan Views to update existing projects)<br />
</li><br />
<li><br />
Provided shortcut keys to quickly switch among the three views. Ctrl+Shift+1 for Top, Ctrl+Shift+2 for Most, Ctrl+Shift+3 for All.<br />
</li><br />
<li><br />
Provided a new Lite attribute, <b>report-priorities</b>, to specify the priorities to include in the generated report.<br />
</li><br />
</ol><br />
</li><br />
<li><b>Password Encryption for Enterprise Servers:</b><br />
Companies with their own Globalyzer Server must provide some configuration information in the GzserverConfig.groovy file.<br />
This information includes some passwords: the database user password and, if the server is configured to use LDAP, an LDAP password.<br />
These passwords may now be encrypted via a new utility: <b>globalyzer-encrypt-password.jar</b> and the encrypted password may be specified in the<br />
GzserverConfig.groovy file.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.2.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.2 release==<br />
<ul><br />
<li><b>Import Lite Project Definition Files:</b><br />
The Workbench can now import Lite Project Definition files, reading from the file to create<br />
a project with scans in the Workbench.<br />
Also, if you are creating an Eclipse project and the base path of the project contains a lingoport/LiteProjectDefinition.xml file, <br />
you may choose to automatically import the file. <br />
In this way you can quickly point to a repo and create the Workbench project from the Lite file in the repo.<br />
</li><br />
<li><b>Support for Android String Externalization:</b><br />
Globalyzer now supports a new resource type, named android, available for both Java and XML scans.<br />
Externalizing to the android resource file writes strings to the file: strings.xml.<br />
</li><br />
<li><b>Rule Set Comparison from the Workbench:</b><br />
From the Workbench, you may now select two rule sets and generate a report comparing them. Previously, this feature was only available from our Command Line Interface.<br />
For example, you can create a default rule set and then extend it, adding/deleting/modifying rules. To see the differences, compare the base rule set with your modified rule set.<br />
</li><br />
<li><b>String Statement Filters for most Rule Set Languages:</b><br />
Originally, String Statement Filters were only implemented for JavaScript. Now, they are available for all languages that support the notion of statements; for example: Java, C#, C++, etc.<br />
If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
</li><br />
<li><b>Improvements regarding Temporary Rules:</b><br />
In the Workbench, you can create temporary rules and scan with them without adding them to rule sets. You may<br />
now see these temporary rules across projects and choose to either delete or submit them. Select Project->Show/Submit Rule Set Filters/Detections menu item in the Workbench.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and provides the following new features:<br />
</p><br />
<ul><br />
<li><b>Introducing Prediction Reports:</b><br />
Prediction Reports are used to save prediction markings, one report per scan. <br />
After marking the predictions for a scan, choose <b>Machine Learning->Export Prediction Report</b> to generate a scan's Prediction Report. <br />
These reports can then be shared with <br />
Globalyzer Lite, other Workbenches, and be reflected in the Dashboard. <br />
Globalyzer Lite will automatically apply the Prediction Report after scanning; <br />
other Workbenches can import the Prediction Report to update their Scan Results with the latest markings; <br />
and the Dashboard, which relies on Globalyzer Lite, will now display the same Scan Results and <br />
predictions shown in the Workbench.<br />
Remember that to speed up your i18n analysis, use <b>Machine Learning->GO!</b> It will use your T/F predictions to make additional predictions.<br />
</li><br />
<li><b>Set Prediction column rather than ToDo, Invalid, and Ignore Status:</b><br><br />
We are deprecating the use of <b>ToDo</b>, <b>Invalid</b>, and <b>Ignore</b> status in favor of<br />
marking the prediction of an issue T/F/P. <br />
<ul><br />
<li>Rather than changing the status of an issue to ToDo, set the prediction to T.</li><br />
<li>Rather than changing the status of an issue to Invalid, set the prediction to F.</li><br />
<li>Rather than changing the status of an issue to Ignore, set the prediction to P (for pending).</li><br />
</ul><br />
After marking your predictions, choose <b>Machine Learning->Export Prediction Report</b><br />
so that your new predictions will be reflected in the Dashboard and can be shared with other<br />
Workbenches.<br />
</li><br />
<li><b>Dashboard False Positive Changes:</b><br />
In our 6.0 release, we added support for synchronizing false positive issues between the <br />
Dashboard and the Workbench using a DFP status.<br />
We are deprecating the DFP status in favor of a DFP prediction value.<br />
Now, <b>Reload Dashboard False Positives</b> will set the prediction value for all<br />
the False Positives on the Dashboard to DFP in the Workbench. Issues with a DFP prediction value can be ignored.<br />
Also, it is no longer necessary to <b>Update to Dashboard as False Positive</b>. Simply mark the prediction F<br />
and export the Prediction Report. Issues marked F will not be displayed on the Dashboard.<br />
To clear a DFP, go to the issue on the Dashboard and make it active again.<br />
</li><br />
<li><b>New Scan Views:</b><br />
We added the following default Scan Views to easily view active issues with various prediction values:<br />
<ul><br />
<li>All Scan Issues - All issues found by scanning, regardless of prediction value</li><br />
<li>All Predicted Active - All issues except those that you, GO!, or the Dashboard<br />
set to False (F, ML False, DFP). These issues are reflected in the Workbench Scan Summary and<br />
in the Dashboard.</li><br />
<li>All Working Active - All issues except those that you have explicitly set to F, or that the<br />
Dashboard set to DFP. Use <b>GO!</b> to speed up the evaluation process.</li><br />
<li>All Undecided - All issues without a set prediction value of T/F/P/DFP.<br />
These are the issues that you still need to evaluate.</li><br />
<li>Prediction T - All active issues with prediction marked T</li><br />
<li>Prediction F - All active issues with prediction marked F</li><br />
<li>Prediction P - All active issues with prediction marked P (pending)</li><br />
<li>Prediction DFP - All active issues with prediction marked DFP</li><br />
</ul><br />
</li><br />
<li><b>Sharing GO! Results:</b><br />
In the Workbench, you automatically generate Machine Learning and<br />
Prediction Report files for a scan <br />
by selecting <b>Machine Learning->GO!</b><br />
These predictions can then be shared with other Workbenches and reflected in the Dashboard.<br />
If you would like to apply existing Machine Learning files to your Scan Results,<br />
you can select <b>Machine Learning->Import Machine Learning</b>. Run <b>GO!</b> whenever you<br />
add or modify T/F/P predictions, so that GO! can make more predictions that are then saved in the<br />
Machine Learning and Prediction Report files.<br />
</li><br />
<li><b>Globalyzer Command Line Client and Machine Learning:</b><br />
When running a scan via the Globalyzer Command Line Client (CLI), you can now apply existing Machine Learning files via a new <b>--machine-learning</b> flag. New code will then be predicted. Note, you still must generate the Machine Learning files for a scan via the Workbench's <b>Machine Learning->GO!</b><br />
</li><br />
<li><b>Scan Reports and Prediction Value:</b><br />
By default, all reports generated from the Workbench, CLI, and Lite will contain only Predicted Active results. This means that results with a prediction value of F, ML False, or DFP will not be reported. XML reports generated from Lite are the exception, and contain results for all prediction values. In the Workbench, you can now configure detailed reports to contain desired prediction values.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1 release==<br />
* '''Introducing Machine Learning''': Machine Learning is a powerful new feature that helps users more quickly identify the real issues in their source code. After scanning with Rule Sets in the Workbench, the user marks some active issues as TRUE or FALSE and then invokes Machine Learning to make predictions on the remaining active issues. It may predict ML True (a real issue), ML False (a false issue), or ML NULL (not enough information to make a prediction). This is an iterative process; the user can make corrections by marking more predictions as TRUE or FALSE and re-invoking Machine Learning, until the prediction results are satisfactory. At this point, the issues predicted as TRUE, ML True, or ML NULL are the ones to address. <br />
* '''Company Dictionary''': This feature allows users to add words to their Globalyzer Company's dictionary when scanning. A Company Dictionary is maintained on the Globalyzer Server. Users can upload, download, and view their dictionary contents. To add words to the dictionary, download the dictionary from the Server, modify the dictionary file on your local machine, and upload to the Server. Note that there is one Company Dictionary per company, so all users within the company will see the same dictionary contents. To use the Company Dictionary, download the dictionary from the server and place in your Lingoport directory. When scanning, Globalyzer will include the words from your downloaded dictionary file along with those in the Lingoport Dictionary. <br />
* '''Import Rule Set Enhancement''': You can now export all your rule sets to a single Rule Set Repository file. And then, when importing from this file, you can select just a subset of the Rule Sets to import. <br />
* '''Updated Rule Terminology''': We changed some of our Globalyzer Rule names to be clearer and more consistent: <br />
** String Literal Filters are now String Content Filters<br />
** String Retention Patterns are now String Content Patterns<br />
** String Operand Filters are now String Variable Filters<br />
** String Operand Patterns are now String Variable Patterns<br />
* '''Globalyzer Server requires Tomcat 8.5.x''': The 6.1 release of the Globalyzer Server has been upgraded to use Grails 3, which requires Tomcat 8.5.x (for our Enterprise users).<br />
<br />
==The following lists new features in the Globalyzer 6.0 release==<br />
* '''Support for Local Rule Sets using Lite''': This feature allows scanning to occur without accessing the Globalyzer Server. Rule sets are stored in local files, rather than retrieved from the Server. Use of this feature requires a Globalyzer License to be downloaded from the Server and stored on your local machine. Also note that this feature is only available for Globalyzer Lite. The Workbench, for example, still requires a connection to the Globalyzer Server.<br />
* '''Dashboard False Positive''': A new status has been implemented for Globalyzer, called Dashboard False Positive, or DFP. This status allows the false positives manually ignored in the Workbench (via status changes) to be reflected on the Dashboard. When an issue is set to DFP, the Dashboard is updated and the issue is ignored. The Workbench can also update its list of DFP issues from the Dashboard, allowing the Workbench to ignore false positives found and set by other developers.<br />
* '''Lite Jenkins Plugin''': On-boarding a Globalyzer Lite Jenkins job is made easy by the new Jenkins Plugins.<br />
* '''Security Enhancements''': Several security enhancements have been implemented for the Globalyzer Server. Our password encryption algorithm has been upgraded to use bcrypt, forgot password now performs a password reset rather than retrieval, and we now guard against clickjacking and directory/path traversal attacks. Our version of Tomcat has been upgraded to enable some of these security features.<br />
* '''Report Enhancements''': Previously, generating reports from the Workbench only included issues with Active or Todo status. Now, you can choose the statuses of interest, generating a report of Filtered issues, for instance.<br />
<br />
==The following lists new features in the Globalyzer 5.4 release==<br />
* '''Support for 4-byte UTF-8 Characters''': Updates the MySQL database used by the Globalyzer Server (and the Globalyzer Workbench if installed to use MySQL) to accept 4-byte characters, such as 𡇙. Previously, only supported up to 3-byte UTF-8 characters. Note that your MySQL version must be 5.5.3 or later and MySQL variable settings must be updated to utf8mb4. Instructions are available in Server upgrade documentation as well as Client download and installation directions.<br />
* '''Introducing json as a resource type for JavaScript''': JavaScript embedded strings can now be externalized to json files.<br />
<br />
==The following lists new features in the Globalyzer 5.3 release==<br />
<p><br />
<ul><br />
<li><b>Introducing the Swift Rule Set:</b><br />
We added a new Rule Set to support the Swift programming language. It contains rules for<br />
Embedded Strings, Locale-Sensitive Methods, Static File References, and General Patterns.<br />
</li><br />
<li><b>Enhanced Perl Rule Set:</b><br />
In release 5.2, we added support for Perl Locale-Sensitive Methods, but no content. In this release, <br />
we provide Locale-Sensitive Methods and their corresponding help, in addition to new rules in other categories.<br />
</li><br />
<li><b>Introducing the Globalyzer MVN Plugin:</b><br />
MVN projects can be scanned using our Globalyzer MVN plugin. <br />
The Globalyzer MVN plugin scans your MVN project and generates scan reports to a directory <br />
specified in the pom.xml file. <br />
We ask our MVN customers to install the MVN plugin in a <br />
private MVN repository for your company. Once installed, all developers<br />
can then access the plugin to scan their code.<br />
</li><br />
</ul><br />
</p><br />
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Note:</b> As of 5.3, all Globalyzer Clients are compiled with <b>Java 8</b>;<br />
to run a client, you must have <b>Java 8 (or later)</b> installed on your machine.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 5.2.1 release ==<br />
This release provides an update to the '''Globalyzer Workbench''' (5.2.1): It is now based on '''Eclipse version 4.6''' (Neon) which runs on '''Java 8'''. The previous version of the Workbench (5.2.0) was based on Eclipse 3.7 and is now deprecated. Workbench 5.2.0 is kept for those clients with previous version of Java, like Java 7. However, we strongly recommend using Workbench 5.2.1 and Java 8.<br />
<br />
==The following lists new features in the Globalyzer 5.2 release==<br />
* '''Introducing Rule Categories''': Rules now have a new Category attribute that allows rules across the rule set to be grouped. Rules can then be quickly enabled/disabled according to category from the Edit Rule Set page.<br />
* '''Enhanced JavaScript Rule Set''' includes jQuery, AngularJS, ReactJS, and NodeJS specific rules: These new rules use the Category attribute to identify the JavaScript library associated with the rule. From the Edit Rule Set page, enable or disable rules for the JavaScript Library Categories to more effectively scan your code. New detection and filter rules have been added to scan code that uses<br />
**'''jQuery'''<br />
**'''AngularJS'''<br />
**'''ReactJS'''<br />
**and '''NodeJS''' libraries.<br />
*New Filter Type for JavaScript Rule Sets - '''String Statement Filters''': If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
*Support for '''HTML Tag Libraries''': Globalyzer now supports skipping Tag Library tags during its HTML Embedded String scan, resulting in cleaner scan results. The Tag Library tags are configured in the Ignored HTML Tags rules.<br />
*Locale-Sensitive Method Support for the '''Perl Rule Set''': You can now configure Locale-Sensitive Methods for Perl Rule Sets.<br />
*Support for Mason Files: Globalyzer can now scan Mason Files, which are files containing JavaScript, HTML, and Perl.<br />
<br />
==The following lists new features in the Globalyzer 5.1 release ==<br />
*'''Finer control configuring Locale-Sensitive Methods for Java:''' There are two new fields when configuring Locale-Sensitive Methods for Java, Class or Variable Type and Parameter Type(s) to Filter. If the Class or Variable Type is specified, then only method calls for this class will be detected. If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method will not be detected. <br />
**For example, you can now configure ''toLowerCase'' to be detected only when called via the ''java.lang.String'' class only if a ''java.util.Locale'' parameter has not been provided.<br />
*'''Globalyzer Lite and API Enhancements''': Globalyzer Lite and the API now support setting session and scan options, similar to what is already available in the Globalyzer Workbench. These new options include: <br />
**the location of the data dictionary<br />
**whether or not to filter results against the dictionary<br />
**the scan timeout duration, source file encoding, result types to scan<br />
**comment text.<br />
*'''Globalyzer Lite Login Feature''': You can now set default login information for Globalyzer Lite by creating a '''.globalyzerrc''' file. When processing Project Definition Files, Lite will grab the username/password information from the .globalyzerrc file if it is not provided in the Project Definition File itself.<br />
For more detailed information on 5.1 features, please go to [[Globalyzer 5.1 Features|Globalyzer 5.1 Features]]<br />
<br />
==The following lists new features in the Globalyzer 5.0 release ==<br />
<br />
*'''String Concatenation Detection''': Globalyzer now flags string literals that are part of string concatenations, helping you to easily identify and refactor the concatenation before externalizing strings to resource files. As Globalyzer scans your source code, it sets a detected string's Scan Results priority to the new string concatenation priority 'C' when at least one of the following conditions are true:<br />
**string literal starts or ends with white space<br />
**string literal is preceded or followed by (language specific) concatenation characters<br />
**string literal is a parameter to a Locale-Sensitive Method configured to have priority 0 (the string concatenation priority)<br />
** See [[Globalyzer Concatenation]]<br />
*Finer control when configuring '''String Method Filters and String Method Patterns''' for Java: When configuring String Method Filters and String Method Patterns for your Java Rule Set, you can now optionally include Class or Variable Type(s) to give you finer control over issues being filtered/detected. For example, rather than filtering all strings passed to the method, setName, you can associate a Class name so filtering will only take place when the embedded string is passed to the setName method of the specified Class.<br />
** See [[Globalyzer 5 Java_Rules]]<br />
*Globalyzer Lite Project Definition File '''Generation from Workbench''': Save time setting up Globalyzer Lite by generating your Globalyzer Lite Project Definition File from the Workbench. Create your Workbench Project and then select <code>File->Export->Globalyzer->Export Project Definition (Lite)</code>.<br />
<br />
==The following lists new features in the Globalyzer 4.8.5 release ==<br />
This release focuses on Globalyzer Lite features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports '''navigating to a candidate issue''' within an IDE by '''clicking on the issue''' in the IDE console window. The documentation covers integration within Visual Studio, IntelliJ IDEA, and Eclipse. Integration with numerous other IDEs is also possible.<br />
**'''Build Integration''': Added new command line option to specify the type of console output at the command line.<br />
<br />
==The following lists new features in the Globalyzer 4.8.3 release ==<br />
This release includes bug fixes and these features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports finding and correcting internationalization issues entirely within an IDE. Our documentation covers integration within '''Visual Studio, IntelliJ IDEA, and Eclipse'''. Integration with numerous '''other IDEs''' is also possible.<br />
**'''Build Integration''': Added new command line options. The project location, scan items, and report directory can now be easily specified at runtime.<br />
<br />
* '''Enhanced Configuration Options''' for Enterprise Servers: <br />
**Enterprise Servers can now configure information and links that display on the Login screen, as well as messages that display for LDAP-configured servers. <br />
**In addition, a default team name may be configured; if specified, newly created users will automatically be assigned to the default team.<br />
<br />
==The following lists new features in the Globalyzer 4.8 release==<br />
<br />
*Introducing '''Globalyzer Lite''': Globalyzer Lite is a lightweight version of the Globalyzer Client. <br />
** It is smaller and faster to install than the Globalyzer Workbench and CLI.<br />
** It requires no external database. <br />
** A '''Project Definition XML''' file allows for the creation of temporary projects and scans, execution of those scans, and generation of corresponding reports. This can be particularly useful in a Continuous Integration model. <br />
** Multiple projects can be processed simultaneously on the same machine.<br />
** '''Note''': This feature requires special licensing. Please contact sales@lingoport.com.<br />
*Globalyzer Server Runs on '''Java 8''': The 4.8 release upgrades the Globalyzer server to run on Java 1.8 (for our Enterprise users). <br />
<br />
'''Note''': Tomcat 7 is now required for deploying the 4.8 Globalyzer Server.<br />
<br />
==The following lists new features in the Globalyzer 4.7 release==<br />
<br />
'''Note''': As of the 4.6 Release, Globalyzer requires Java 1.7. Please make sure that JDK 1.7 is installed on your machine before attempting to install the Globalyzer Client.<br />
<br />
*'''The Globalyzer API''': The Globalyzer API allows you to create Globalyzer projects and scans, execute scans, and generate reports from a java program. This enables projects to be created "on the fly." For example, during code check-in, the check-in process could trigger the execution of a java program that calls the API to scan the source code, enabling timely feedback on its internationalization status. See the Globalyzer API reference page for more information on how to use this new feature.<br />
*'''LDAP for Enterprise Servers''': The Globalyzer Server can be configured to use your company's LDAP system. All Globalyzer user access and information is then managed by LDAP. '''Note''': This feature requires ''special licensing''. Please contact sales@lingoport.com.<br />
*'''Improved Rule Sets''': Updated Globalyzer default rule sets, with specific attention on JavaScript and Objective-C.<br />
<br />
Should you encounter problems or have questions, please email ''support@lingoport.com''.<br />
<br />
==The following lists new features in the Globalyzer 4.6 release==<br />
<br />
*'''Introducing String Operand Filters/Patterns''': This feature (available for all languages except HTML) allows you to filter/retain string literals that are compared with, or assigned to, variables. For languages such as XML, you can use this to filter out string attributes.<br />
*'''Filter Strings used as Array Indices for C#, PHP, and JavaScript''': C#, PHP, and JavaScript support Associative Arrays, where strings can be used to index arrays. String literals used in this manner are not user-facing and should be filtered. This filtering is now performed automatically; there is no Rule Set configuration work required. Note that this has only been implemented for C#, PHP, and JavaScript.<br />
*'''Managers can Assign Ownership of Rule Sets''': Prior to this feature, only Rule Set owners could assign their Rule Sets to another user within the company. Now, managers can assign Rule Sets of team members to other users within the company.<br />
*'''Email False Positive Scan Results to Lingoport''': Feedback from Globalyzer users regarding false positive Scan Results has been invaluable. To help facilitate this feedback, the Workbench now allows the user to select entries in Scan Results and email them to Lingoport via a menu selection. This information will help us further refine our default Rule Sets.<br />
*'''Improved JavaScript Rule Set''': New filters have been added to the JavaScript Rule Set and help for JavaScript Locale-Sensitive Methods has been enhanced.<br />
*'''Secure HTTP''': Globalyzer now supports the additional security of HTTPS for all data that passes between the Client and the globalyzer.com Server.<br />
*'''New version command for the Command Line Client''': The Globalyzer Command Line Client now supports --version and -ver to provide version information for both the Client and the Server.<br />
*'''String Method Filters/Patterns now filter/retain Strings within Nested Methods''': If string literals are passed to a nested method, they will be filtered if the outer method is a String Method Filter, and retained if the outer method is a String Method Pattern.<br />
*'''Reason Field in Scan Results more Descriptive for Embedded Strings''': In addition to displaying the pattern of the rule (that either filtered or retained the Embedded String), the Reason field now includes "Literal", "Line", "Method", or "Operand", to indicate the type of the rule.<br />
*'''Reorganization of Reference Section Help''': The Reference Section Help has been organized into Command Line, Server, and Workbench Reference sections.<br />
<br />
==The following lists new features in the Globalyzer 4.5 release==<br />
<br />
*'''Rule Set Inheritance''': Rule Sets now support inheritance! A Rule Set can be created to extend an existing Rule Set. The new Rule Set inherits all the rules of the parent Rule Set and can add new rules and/or override inherited rules. This allows companies to centrally manage core Rule Sets and project teams can then inherit the modifications.<br />
*'''Comparing Rule Sets''': Available from the Command Line Interface, Rule Sets defined on the server can now be compared, generating an HTML report with the differences.<br />
*'''Support for Android''': The Java Rule Set has been enhanced to support android applications. New String Method Filters, String Literal Filters, and String Line Filters have been added to weed out false positive Embedded Strings.<br />
*'''Time Stamps in Console Output and in Show Log''': Time Stamps have been added to the Console output as well as the Show Log HTML page.<br />
*'''Updated RESX Resource File''': The generated RESX Resource File has been updated from version 1.3 to 2.0.<br />
Our '''4.3.1''' release made a few important tuning and performance improvements in the areas of MySQL Client database support, scanning, and the File Inspector.<br />
<br />
==The following lists new features in the Globalyzer 4.3 release==<br />
<br />
*'''Shared Globalyzer Projects''': Globalyzer project and scan configuration (without scan results) can now be shared. Instead of explicitly importing and exporting projects, Globalyzer manages these tasks automatically, enabling team members to work on the same project seamlessly. See the Shared Projects reference page for more information on how to use this new feature.<br />
*'''Import/Merge''': When importing a Globalyzer project that already exists in your workspace, you now have the option to either Overwrite or Merge. Overwrite deletes your existing project before importing the new one; merge combines the imported project with your existing one.<br />
*'''Globalyzer Data Directory Location''': During Client Installation, you are now prompted for the location of the Data Directory, where Globalyzer stores application data and log files as well as the optional HSQLDB database. The default is [userhome]/.globalyzer, but this can be set to another location.<br />
*'''Additional Help on Headless Globalyzer Install''': Login to the Globalyzer Server and click on the Globalyzer Client download link. The Client Installation download page includes instructions on how to install the Globalyzer Client via a script as opposed to a GUI. You'll want to use this when installing Globalyzer to build machines where Globalyzer scanning can be part of the nightly build.<br />
*'''Suggested Rule Sets for Unsupported Languages''': The Create Rule Set reference page provides Rule Set suggestions for currently unsupported languages.<br />
*'''File Inspector Report Line Counts''': Line counts have been added to File Inspector Reports.<br />
<br />
==The following lists new features in the Globalyzer 4.2 release==<br />
<br />
*'''Objective-C Rule Set''': We've added this important rule set to help you internationalize your iOS and other Objective-C applications. In addition to scanning for i18n issues in Objective-C source code, Globalyzer supports string externalization to Objective-C's preferred text resource file type: strings<br />
*'''Ability to Assign Rule Sets to Others''': Though team members can share rule sets, only the rule set owner can made modifications. This feature facilitates passing rule set ownership to another. Just edit the rule set and select a new owner in the Owner dropdown.<br />
*'''Launch Client without First Creating a Rule Set on the Server''': This feature supports the natural process of using Globalyzer: first create a Project, then run File Inspector, then create Rule Sets and Scans.<br />
*'''Create Rule Sets from the Client''': To facilitate rule set creation, Globalyzer now supports the ability to create new rule sets directly from the Client. You may still want do some customization on the Server, but it's now even easier to create that first set of rule sets as you're running the Client, creating your Globalyzer Project and looking at the results of your File Inspection report to determine which rule sets you'll need for scanning your source code.<br />
*'''Additional default Scan Views''': In addition to All Active, there are now default Scan Views for Priority 1, Priority 2, Priority 1 and 2, Ignore, Invalid, ToDo, Filtered, All, and All but Active and Filtered.<br />
*'''Notification of Newer Globalyzer Versions on Client Startup''': On Client startup, a popup displays if there is a newer version of the Client available or if there is a Client/Server version mismatch; the popup includes a link to the latest Client download.<br />
*'''Demo Results displayed based on Priority''': When a demo user executes scans, up to 100 active results are reported. This feature focuses on reporting mostly higher priority issues. It reports 50 Priority 1 issues, 30 Priority 2 issues, 20 Priority 3 issues, 5 Priority 4 issues, and 5 Priority 5 issues.<br />
<br />
==The following lists new features in the Globalyzer 4.1.1 release==<br />
<br />
*'''Additional options when pseudo-localizing your resource files''':<br />
**Pseudo-localize all your base resource files at one time by using the new '''Localize All''' button.<br />
**Use the new '''Start''' and '''End''' fields to specify characters to be displayed before and after each string. This helps you quickly identify layout issues where the full string is not fitting. For example [String]<br />
**You can also specify that each character of the string itself be replaced by an accented character for easier differentiation from English strings. For example '''Šţŕîñg'''<br />
*'''Support for Delphi RC resource file type''': The Delphi language requires its own version of the RC resource file type. Upon string externalization, a .pas file is created and updated, along with the .h and .rc files.<br />
*'''.NET Tutorial''': To accompany our Java tutorial, the .NET tutorial takes your through the basic steps involved in internationalizing a simple .NET Web application.<br />
<br />
==The following lists new features in the Globalyzer 4.1 release==<br />
<br />
*'''Refine your Rule Set from within the Client''': The Globayzer Client now allows you to create both filter and detection rules, rescan your code to see their effects, and update the Rule Set on the server when you are satisfied with the results. This Scan Result driven approach to fine-tuning your Rule Set should help you significantly streamline your scanning and filtering process.<br />
*'''Prioritize your internationalization work''': Globalyzer now prioritizes its locale-sensitive method, general pattern, and static file reference detections (in addition to embedded string detections implemented in version 3.5), helping you focus on the most likely issues first. These priority settings can be customized. You'll see the priority breakdown both on screen and in the many reports that are provided for you to track and manage your progress.<br />
*'''Retain and prioritize strings passed to specified methods''': Rule Sets now include a new detection, called String Method Patterns. This feature allows you to specifically identify methods that are passed strings that would be displayed to the end user. For example, in javascript we have added confirm, in C# Show, and in java JLabel. By identifying these types of methods and configuring them in your Rule Set, you can set the priority for these string detections and ensure that they are addressed during your internationalization process.<br />
*'''Disable Scan Feature''': Scans can now be disabled. Disabled scans can be configured but are not scanned (automatically or manually) and the scan results are not available/displayed. This feature is useful for limiting the amount of rescanning that occurs when configuring scans. The user can focus on one scan, disabling the others.<br />
*'''All resource types now support group mode''': In group mode, externalized strings are grouped by file in the resource file.<br />
*'''All resource types now support comments:''' Comments can be added to resource files and will be preserved during subsequent string externalizations.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Release_Notes&diff=96973Globalyzer Release Notes2023-01-27T21:56:59Z<p>MaryH: </p>
<hr />
<div>For supported versions, please see:<br />
[[Lingoport_Suite_Installation#Supported_Versions]]<br />
<br />
==Globalyzer 6.8.0 Release Notes (March 2023)==<br />
The 6.8.0 release includes the following new features:<br />
<p><br />
<ul><br />
<li><b>Support for SAML/SSO</b>:<br />
The Globalyzer Server can now be configured with SAML/SSO, in addition to LDAP.<br />
This allows seemless integration with third party identify providers.<br />
</li><br />
<li><b>Support for Command Center</b>:<br />
Command Center is a new Lingoport product that communicates with the Globalyzer Server.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.7.0 release==<br />
<p><br />
<ul><br />
<li><b>Requires JDK11 to run the Globalyzer Client</b>:<br />
You can download from OpenLogic https://www.openlogic.com/openjdk-downloads<br />
</li><br />
<li><b>Password Encryption Changed</b>:<br />
You will be prompted to log in the first time after installing the Workbench.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.6.0 release==<br />
<p><br />
<ul><br />
<li><b>Go Rule Set:</b><br />
Globalyzer now provides a Go rule set to scan Go language code, and supports Go string externalization to json resource files.<br />
</li><br />
<li><b>Locale-Sensitive Method Priority Updates for JavaScript and CSharp Rule Sets:</b><br />
To streamline your internationalization work, we have updated the default priority settings for JavaScript and C# locale-sensitive methods, setting the methods that are most likely to be issues, to priority 1 or 2.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.5.0 release==<br />
<p><br />
<ul><br />
<li><b>Python Rule Set:</b><br />
Globalyzer now provides a python3 rule set to scan python code, and supports python string externalization to either po or properties resource files.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.4.1 release==<br />
The 6.4.1 release involves the Globalyzer Client only (not the Globalyzer Server). This release provides the following enhancements, along with minor bug fixes:<br />
<ul><br />
<li><b>Compressed Prediction Report:</b><br />
The [[ Machine_Learning#Prediction_Reports | prediction report]] for a scan can become quite large. <br />
The generated report is now a zip file, making it easier to check in to version control.<br />
</li><br />
<li><b>Improved Scanning of jsx Files:</b><br />
Jsx files are a mixture of JavaScript and HTML. They are now scanned, by default, by both our JavaScript and HTML rule sets. <br />
Also, HTML scanning of these files has been greatly improved.<br />
</li><br />
<li><b>Improved Scanning of TypeScript Files:</b><br />
The JavaScript rule set has been enhanced to scan ts files. Tsx files (a mixture of TypeScript and HTML), are also scanned by default by both JavaScript and HTML rule sets.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.4.0 release==<br />
<p><br />
<ul><br />
<li><b>Method Statement Filters:</b><br />
These new filters are similar to Method Line Filters, except they apply to a programming language statement, as opposed to a line of code.<br />
If Globalyzer detects a Locale-Sensitive Method, and within the same statement finds a Method Statement Filter,<br />
that method will be excluded from the Locale-Sensitive Method Scan Results.<br />
</li><br />
<li><b>Modified order of Embedded String Filtering and Retention Rules:</b><br />
Prior to this release, the Embedded String scan would first find all strings, then apply all Filtering rules, followed by all Retention rules. <br />
We have found that interleaving Filtering and Retention rules generates better results.<br />
We now apply specific filters and patterns before more general filters and patterns. <br />
For example, a string might be a parameter to a method that is in a line that is part of a statement.<br />
So, if you defined a String Method Pattern to retain an issue, but you have a String Statement Filter that <br />
filters the statement, the issue will ultimately be filtered since the more general, String Statement Filter, is applied last. <br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.0 release==<br />
<ul><br />
<li><b>Concatenation Detection for HTML Strings:</b><br />
HTML strings are sometimes a combination of text, externalized text, server-side code, and in the case of .vm files, variables.<br />
Globalyzer now detects these combinations and will set the priority to C. <br />
Globalyzer also provides a new rule retention for HTML rule sets only, called <b>String Concatenation Patterns</b>,<br />
to find concatenations that would normally be Filtered.<br />
For example, an HTML string which is a series of string externalizations<br />
would not be Active (since the string does not contain text to externalize). <br />
However the string should most likely be externalized as a whole, instead of concatenated parts. <br />
Use a String Concatenation Pattern to find these situations so they can be dealt with properly.<br />
</li><br />
<li><b>Focus on Top Scan Result Issues:</b><br />
Globalyzer has taken a number of steps to help users focus on top issues.<br />
<ol><br />
<li><br />
Defined Scan Views for <b>Top</b>, <b>Most</b>, and <b>All</b> Predicted Issues (select Scan->Refresh Default Scan Views to update existing projects)<br />
</li><br />
<li><br />
Provided shortcut keys to quickly switch among the three views. Ctrl+Shift+1 for Top, Ctrl+Shift+2 for Most, Ctrl+Shift+3 for All.<br />
</li><br />
<li><br />
Provided a new Lite attribute, <b>report-priorities</b>, to specify the priorities to include in the generated report.<br />
</li><br />
</ol><br />
</li><br />
<li><b>Password Encryption for Enterprise Servers:</b><br />
Companies with their own Globalyzer Server must provide some configuration information in the GzserverConfig.groovy file.<br />
This information includes some passwords: the database user password and, if the server is configured to use LDAP, an LDAP password.<br />
These passwords may now be encrypted via a new utility: <b>globalyzer-encrypt-password.jar</b> and the encrypted password may be specified in the<br />
GzserverConfig.groovy file.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.2.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.2 release==<br />
<ul><br />
<li><b>Import Lite Project Definition Files:</b><br />
The Workbench can now import Lite Project Definition files, reading from the file to create<br />
a project with scans in the Workbench.<br />
Also, if you are creating an Eclipse project and the base path of the project contains a lingoport/LiteProjectDefinition.xml file, <br />
you may choose to automatically import the file. <br />
In this way you can quickly point to a repo and create the Workbench project from the Lite file in the repo.<br />
</li><br />
<li><b>Support for Android String Externalization:</b><br />
Globalyzer now supports a new resource type, named android, available for both Java and XML scans.<br />
Externalizing to the android resource file writes strings to the file: strings.xml.<br />
</li><br />
<li><b>Rule Set Comparison from the Workbench:</b><br />
From the Workbench, you may now select two rule sets and generate a report comparing them. Previously, this feature was only available from our Command Line Interface.<br />
For example, you can create a default rule set and then extend it, adding/deleting/modifying rules. To see the differences, compare the base rule set with your modified rule set.<br />
</li><br />
<li><b>String Statement Filters for most Rule Set Languages:</b><br />
Originally, String Statement Filters were only implemented for JavaScript. Now, they are available for all languages that support the notion of statements; for example: Java, C#, C++, etc.<br />
If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
</li><br />
<li><b>Improvements regarding Temporary Rules:</b><br />
In the Workbench, you can create temporary rules and scan with them without adding them to rule sets. You may<br />
now see these temporary rules across projects and choose to either delete or submit them. Select Project->Show/Submit Rule Set Filters/Detections menu item in the Workbench.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and provides the following new features:<br />
</p><br />
<ul><br />
<li><b>Introducing Prediction Reports:</b><br />
Prediction Reports are used to save prediction markings, one report per scan. <br />
After marking the predictions for a scan, choose <b>Machine Learning->Export Prediction Report</b> to generate a scan's Prediction Report. <br />
These reports can then be shared with <br />
Globalyzer Lite, other Workbenches, and be reflected in the Dashboard. <br />
Globalyzer Lite will automatically apply the Prediction Report after scanning; <br />
other Workbenches can import the Prediction Report to update their Scan Results with the latest markings; <br />
and the Dashboard, which relies on Globalyzer Lite, will now display the same Scan Results and <br />
predictions shown in the Workbench.<br />
Remember that to speed up your i18n analysis, use <b>Machine Learning->GO!</b> It will use your T/F predictions to make additional predictions.<br />
</li><br />
<li><b>Set Prediction column rather than ToDo, Invalid, and Ignore Status:</b><br><br />
We are deprecating the use of <b>ToDo</b>, <b>Invalid</b>, and <b>Ignore</b> status in favor of<br />
marking the prediction of an issue T/F/P. <br />
<ul><br />
<li>Rather than changing the status of an issue to ToDo, set the prediction to T.</li><br />
<li>Rather than changing the status of an issue to Invalid, set the prediction to F.</li><br />
<li>Rather than changing the status of an issue to Ignore, set the prediction to P (for pending).</li><br />
</ul><br />
After marking your predictions, choose <b>Machine Learning->Export Prediction Report</b><br />
so that your new predictions will be reflected in the Dashboard and can be shared with other<br />
Workbenches.<br />
</li><br />
<li><b>Dashboard False Positive Changes:</b><br />
In our 6.0 release, we added support for synchronizing false positive issues between the <br />
Dashboard and the Workbench using a DFP status.<br />
We are deprecating the DFP status in favor of a DFP prediction value.<br />
Now, <b>Reload Dashboard False Positives</b> will set the prediction value for all<br />
the False Positives on the Dashboard to DFP in the Workbench. Issues with a DFP prediction value can be ignored.<br />
Also, it is no longer necessary to <b>Update to Dashboard as False Positive</b>. Simply mark the prediction F<br />
and export the Prediction Report. Issues marked F will not be displayed on the Dashboard.<br />
To clear a DFP, go to the issue on the Dashboard and make it active again.<br />
</li><br />
<li><b>New Scan Views:</b><br />
We added the following default Scan Views to easily view active issues with various prediction values:<br />
<ul><br />
<li>All Scan Issues - All issues found by scanning, regardless of prediction value</li><br />
<li>All Predicted Active - All issues except those that you, GO!, or the Dashboard<br />
set to False (F, ML False, DFP). These issues are reflected in the Workbench Scan Summary and<br />
in the Dashboard.</li><br />
<li>All Working Active - All issues except those that you have explicitly set to F, or that the<br />
Dashboard set to DFP. Use <b>GO!</b> to speed up the evaluation process.</li><br />
<li>All Undecided - All issues without a set prediction value of T/F/P/DFP.<br />
These are the issues that you still need to evaluate.</li><br />
<li>Prediction T - All active issues with prediction marked T</li><br />
<li>Prediction F - All active issues with prediction marked F</li><br />
<li>Prediction P - All active issues with prediction marked P (pending)</li><br />
<li>Prediction DFP - All active issues with prediction marked DFP</li><br />
</ul><br />
</li><br />
<li><b>Sharing GO! Results:</b><br />
In the Workbench, you automatically generate Machine Learning and<br />
Prediction Report files for a scan <br />
by selecting <b>Machine Learning->GO!</b><br />
These predictions can then be shared with other Workbenches and reflected in the Dashboard.<br />
If you would like to apply existing Machine Learning files to your Scan Results,<br />
you can select <b>Machine Learning->Import Machine Learning</b>. Run <b>GO!</b> whenever you<br />
add or modify T/F/P predictions, so that GO! can make more predictions that are then saved in the<br />
Machine Learning and Prediction Report files.<br />
</li><br />
<li><b>Globalyzer Command Line Client and Machine Learning:</b><br />
When running a scan via the Globalyzer Command Line Client (CLI), you can now apply existing Machine Learning files via a new <b>--machine-learning</b> flag. New code will then be predicted. Note, you still must generate the Machine Learning files for a scan via the Workbench's <b>Machine Learning->GO!</b><br />
</li><br />
<li><b>Scan Reports and Prediction Value:</b><br />
By default, all reports generated from the Workbench, CLI, and Lite will contain only Predicted Active results. This means that results with a prediction value of F, ML False, or DFP will not be reported. XML reports generated from Lite are the exception, and contain results for all prediction values. In the Workbench, you can now configure detailed reports to contain desired prediction values.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1 release==<br />
* '''Introducing Machine Learning''': Machine Learning is a powerful new feature that helps users more quickly identify the real issues in their source code. After scanning with Rule Sets in the Workbench, the user marks some active issues as TRUE or FALSE and then invokes Machine Learning to make predictions on the remaining active issues. It may predict ML True (a real issue), ML False (a false issue), or ML NULL (not enough information to make a prediction). This is an iterative process; the user can make corrections by marking more predictions as TRUE or FALSE and re-invoking Machine Learning, until the prediction results are satisfactory. At this point, the issues predicted as TRUE, ML True, or ML NULL are the ones to address. <br />
* '''Company Dictionary''': This feature allows users to add words to their Globalyzer Company's dictionary when scanning. A Company Dictionary is maintained on the Globalyzer Server. Users can upload, download, and view their dictionary contents. To add words to the dictionary, download the dictionary from the Server, modify the dictionary file on your local machine, and upload to the Server. Note that there is one Company Dictionary per company, so all users within the company will see the same dictionary contents. To use the Company Dictionary, download the dictionary from the server and place in your Lingoport directory. When scanning, Globalyzer will include the words from your downloaded dictionary file along with those in the Lingoport Dictionary. <br />
* '''Import Rule Set Enhancement''': You can now export all your rule sets to a single Rule Set Repository file. And then, when importing from this file, you can select just a subset of the Rule Sets to import. <br />
* '''Updated Rule Terminology''': We changed some of our Globalyzer Rule names to be clearer and more consistent: <br />
** String Literal Filters are now String Content Filters<br />
** String Retention Patterns are now String Content Patterns<br />
** String Operand Filters are now String Variable Filters<br />
** String Operand Patterns are now String Variable Patterns<br />
* '''Globalyzer Server requires Tomcat 8.5.x''': The 6.1 release of the Globalyzer Server has been upgraded to use Grails 3, which requires Tomcat 8.5.x (for our Enterprise users).<br />
<br />
==The following lists new features in the Globalyzer 6.0 release==<br />
* '''Support for Local Rule Sets using Lite''': This feature allows scanning to occur without accessing the Globalyzer Server. Rule sets are stored in local files, rather than retrieved from the Server. Use of this feature requires a Globalyzer License to be downloaded from the Server and stored on your local machine. Also note that this feature is only available for Globalyzer Lite. The Workbench, for example, still requires a connection to the Globalyzer Server.<br />
* '''Dashboard False Positive''': A new status has been implemented for Globalyzer, called Dashboard False Positive, or DFP. This status allows the false positives manually ignored in the Workbench (via status changes) to be reflected on the Dashboard. When an issue is set to DFP, the Dashboard is updated and the issue is ignored. The Workbench can also update its list of DFP issues from the Dashboard, allowing the Workbench to ignore false positives found and set by other developers.<br />
* '''Lite Jenkins Plugin''': On-boarding a Globalyzer Lite Jenkins job is made easy by the new Jenkins Plugins.<br />
* '''Security Enhancements''': Several security enhancements have been implemented for the Globalyzer Server. Our password encryption algorithm has been upgraded to use bcrypt, forgot password now performs a password reset rather than retrieval, and we now guard against clickjacking and directory/path traversal attacks. Our version of Tomcat has been upgraded to enable some of these security features.<br />
* '''Report Enhancements''': Previously, generating reports from the Workbench only included issues with Active or Todo status. Now, you can choose the statuses of interest, generating a report of Filtered issues, for instance.<br />
<br />
==The following lists new features in the Globalyzer 5.4 release==<br />
* '''Support for 4-byte UTF-8 Characters''': Updates the MySQL database used by the Globalyzer Server (and the Globalyzer Workbench if installed to use MySQL) to accept 4-byte characters, such as 𡇙. Previously, only supported up to 3-byte UTF-8 characters. Note that your MySQL version must be 5.5.3 or later and MySQL variable settings must be updated to utf8mb4. Instructions are available in Server upgrade documentation as well as Client download and installation directions.<br />
* '''Introducing json as a resource type for JavaScript''': JavaScript embedded strings can now be externalized to json files.<br />
<br />
==The following lists new features in the Globalyzer 5.3 release==<br />
<p><br />
<ul><br />
<li><b>Introducing the Swift Rule Set:</b><br />
We added a new Rule Set to support the Swift programming language. It contains rules for<br />
Embedded Strings, Locale-Sensitive Methods, Static File References, and General Patterns.<br />
</li><br />
<li><b>Enhanced Perl Rule Set:</b><br />
In release 5.2, we added support for Perl Locale-Sensitive Methods, but no content. In this release, <br />
we provide Locale-Sensitive Methods and their corresponding help, in addition to new rules in other categories.<br />
</li><br />
<li><b>Introducing the Globalyzer MVN Plugin:</b><br />
MVN projects can be scanned using our Globalyzer MVN plugin. <br />
The Globalyzer MVN plugin scans your MVN project and generates scan reports to a directory <br />
specified in the pom.xml file. <br />
We ask our MVN customers to install the MVN plugin in a <br />
private MVN repository for your company. Once installed, all developers<br />
can then access the plugin to scan their code.<br />
</li><br />
</ul><br />
</p><br />
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Note:</b> As of 5.3, all Globalyzer Clients are compiled with <b>Java 8</b>;<br />
to run a client, you must have <b>Java 8 (or later)</b> installed on your machine.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 5.2.1 release ==<br />
This release provides an update to the '''Globalyzer Workbench''' (5.2.1): It is now based on '''Eclipse version 4.6''' (Neon) which runs on '''Java 8'''. The previous version of the Workbench (5.2.0) was based on Eclipse 3.7 and is now deprecated. Workbench 5.2.0 is kept for those clients with previous version of Java, like Java 7. However, we strongly recommend using Workbench 5.2.1 and Java 8.<br />
<br />
==The following lists new features in the Globalyzer 5.2 release==<br />
* '''Introducing Rule Categories''': Rules now have a new Category attribute that allows rules across the rule set to be grouped. Rules can then be quickly enabled/disabled according to category from the Edit Rule Set page.<br />
* '''Enhanced JavaScript Rule Set''' includes jQuery, AngularJS, ReactJS, and NodeJS specific rules: These new rules use the Category attribute to identify the JavaScript library associated with the rule. From the Edit Rule Set page, enable or disable rules for the JavaScript Library Categories to more effectively scan your code. New detection and filter rules have been added to scan code that uses<br />
**'''jQuery'''<br />
**'''AngularJS'''<br />
**'''ReactJS'''<br />
**and '''NodeJS''' libraries.<br />
*New Filter Type for JavaScript Rule Sets - '''String Statement Filters''': If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
*Support for '''HTML Tag Libraries''': Globalyzer now supports skipping Tag Library tags during its HTML Embedded String scan, resulting in cleaner scan results. The Tag Library tags are configured in the Ignored HTML Tags rules.<br />
*Locale-Sensitive Method Support for the '''Perl Rule Set''': You can now configure Locale-Sensitive Methods for Perl Rule Sets.<br />
*Support for Mason Files: Globalyzer can now scan Mason Files, which are files containing JavaScript, HTML, and Perl.<br />
<br />
==The following lists new features in the Globalyzer 5.1 release ==<br />
*'''Finer control configuring Locale-Sensitive Methods for Java:''' There are two new fields when configuring Locale-Sensitive Methods for Java, Class or Variable Type and Parameter Type(s) to Filter. If the Class or Variable Type is specified, then only method calls for this class will be detected. If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method will not be detected. <br />
**For example, you can now configure ''toLowerCase'' to be detected only when called via the ''java.lang.String'' class only if a ''java.util.Locale'' parameter has not been provided.<br />
*'''Globalyzer Lite and API Enhancements''': Globalyzer Lite and the API now support setting session and scan options, similar to what is already available in the Globalyzer Workbench. These new options include: <br />
**the location of the data dictionary<br />
**whether or not to filter results against the dictionary<br />
**the scan timeout duration, source file encoding, result types to scan<br />
**comment text.<br />
*'''Globalyzer Lite Login Feature''': You can now set default login information for Globalyzer Lite by creating a '''.globalyzerrc''' file. When processing Project Definition Files, Lite will grab the username/password information from the .globalyzerrc file if it is not provided in the Project Definition File itself.<br />
For more detailed information on 5.1 features, please go to [[Globalyzer 5.1 Features|Globalyzer 5.1 Features]]<br />
<br />
==The following lists new features in the Globalyzer 5.0 release ==<br />
<br />
*'''String Concatenation Detection''': Globalyzer now flags string literals that are part of string concatenations, helping you to easily identify and refactor the concatenation before externalizing strings to resource files. As Globalyzer scans your source code, it sets a detected string's Scan Results priority to the new string concatenation priority 'C' when at least one of the following conditions are true:<br />
**string literal starts or ends with white space<br />
**string literal is preceded or followed by (language specific) concatenation characters<br />
**string literal is a parameter to a Locale-Sensitive Method configured to have priority 0 (the string concatenation priority)<br />
** See [[Globalyzer Concatenation]]<br />
*Finer control when configuring '''String Method Filters and String Method Patterns''' for Java: When configuring String Method Filters and String Method Patterns for your Java Rule Set, you can now optionally include Class or Variable Type(s) to give you finer control over issues being filtered/detected. For example, rather than filtering all strings passed to the method, setName, you can associate a Class name so filtering will only take place when the embedded string is passed to the setName method of the specified Class.<br />
** See [[Globalyzer 5 Java_Rules]]<br />
*Globalyzer Lite Project Definition File '''Generation from Workbench''': Save time setting up Globalyzer Lite by generating your Globalyzer Lite Project Definition File from the Workbench. Create your Workbench Project and then select <code>File->Export->Globalyzer->Export Project Definition (Lite)</code>.<br />
<br />
==The following lists new features in the Globalyzer 4.8.5 release ==<br />
This release focuses on Globalyzer Lite features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports '''navigating to a candidate issue''' within an IDE by '''clicking on the issue''' in the IDE console window. The documentation covers integration within Visual Studio, IntelliJ IDEA, and Eclipse. Integration with numerous other IDEs is also possible.<br />
**'''Build Integration''': Added new command line option to specify the type of console output at the command line.<br />
<br />
==The following lists new features in the Globalyzer 4.8.3 release ==<br />
This release includes bug fixes and these features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports finding and correcting internationalization issues entirely within an IDE. Our documentation covers integration within '''Visual Studio, IntelliJ IDEA, and Eclipse'''. Integration with numerous '''other IDEs''' is also possible.<br />
**'''Build Integration''': Added new command line options. The project location, scan items, and report directory can now be easily specified at runtime.<br />
<br />
* '''Enhanced Configuration Options''' for Enterprise Servers: <br />
**Enterprise Servers can now configure information and links that display on the Login screen, as well as messages that display for LDAP-configured servers. <br />
**In addition, a default team name may be configured; if specified, newly created users will automatically be assigned to the default team.<br />
<br />
==The following lists new features in the Globalyzer 4.8 release==<br />
<br />
*Introducing '''Globalyzer Lite''': Globalyzer Lite is a lightweight version of the Globalyzer Client. <br />
** It is smaller and faster to install than the Globalyzer Workbench and CLI.<br />
** It requires no external database. <br />
** A '''Project Definition XML''' file allows for the creation of temporary projects and scans, execution of those scans, and generation of corresponding reports. This can be particularly useful in a Continuous Integration model. <br />
** Multiple projects can be processed simultaneously on the same machine.<br />
** '''Note''': This feature requires special licensing. Please contact sales@lingoport.com.<br />
*Globalyzer Server Runs on '''Java 8''': The 4.8 release upgrades the Globalyzer server to run on Java 1.8 (for our Enterprise users). <br />
<br />
'''Note''': Tomcat 7 is now required for deploying the 4.8 Globalyzer Server.<br />
<br />
==The following lists new features in the Globalyzer 4.7 release==<br />
<br />
'''Note''': As of the 4.6 Release, Globalyzer requires Java 1.7. Please make sure that JDK 1.7 is installed on your machine before attempting to install the Globalyzer Client.<br />
<br />
*'''The Globalyzer API''': The Globalyzer API allows you to create Globalyzer projects and scans, execute scans, and generate reports from a java program. This enables projects to be created "on the fly." For example, during code check-in, the check-in process could trigger the execution of a java program that calls the API to scan the source code, enabling timely feedback on its internationalization status. See the Globalyzer API reference page for more information on how to use this new feature.<br />
*'''LDAP for Enterprise Servers''': The Globalyzer Server can be configured to use your company's LDAP system. All Globalyzer user access and information is then managed by LDAP. '''Note''': This feature requires ''special licensing''. Please contact sales@lingoport.com.<br />
*'''Improved Rule Sets''': Updated Globalyzer default rule sets, with specific attention on JavaScript and Objective-C.<br />
<br />
Should you encounter problems or have questions, please email ''support@lingoport.com''.<br />
<br />
==The following lists new features in the Globalyzer 4.6 release==<br />
<br />
*'''Introducing String Operand Filters/Patterns''': This feature (available for all languages except HTML) allows you to filter/retain string literals that are compared with, or assigned to, variables. For languages such as XML, you can use this to filter out string attributes.<br />
*'''Filter Strings used as Array Indices for C#, PHP, and JavaScript''': C#, PHP, and JavaScript support Associative Arrays, where strings can be used to index arrays. String literals used in this manner are not user-facing and should be filtered. This filtering is now performed automatically; there is no Rule Set configuration work required. Note that this has only been implemented for C#, PHP, and JavaScript.<br />
*'''Managers can Assign Ownership of Rule Sets''': Prior to this feature, only Rule Set owners could assign their Rule Sets to another user within the company. Now, managers can assign Rule Sets of team members to other users within the company.<br />
*'''Email False Positive Scan Results to Lingoport''': Feedback from Globalyzer users regarding false positive Scan Results has been invaluable. To help facilitate this feedback, the Workbench now allows the user to select entries in Scan Results and email them to Lingoport via a menu selection. This information will help us further refine our default Rule Sets.<br />
*'''Improved JavaScript Rule Set''': New filters have been added to the JavaScript Rule Set and help for JavaScript Locale-Sensitive Methods has been enhanced.<br />
*'''Secure HTTP''': Globalyzer now supports the additional security of HTTPS for all data that passes between the Client and the globalyzer.com Server.<br />
*'''New version command for the Command Line Client''': The Globalyzer Command Line Client now supports --version and -ver to provide version information for both the Client and the Server.<br />
*'''String Method Filters/Patterns now filter/retain Strings within Nested Methods''': If string literals are passed to a nested method, they will be filtered if the outer method is a String Method Filter, and retained if the outer method is a String Method Pattern.<br />
*'''Reason Field in Scan Results more Descriptive for Embedded Strings''': In addition to displaying the pattern of the rule (that either filtered or retained the Embedded String), the Reason field now includes "Literal", "Line", "Method", or "Operand", to indicate the type of the rule.<br />
*'''Reorganization of Reference Section Help''': The Reference Section Help has been organized into Command Line, Server, and Workbench Reference sections.<br />
<br />
==The following lists new features in the Globalyzer 4.5 release==<br />
<br />
*'''Rule Set Inheritance''': Rule Sets now support inheritance! A Rule Set can be created to extend an existing Rule Set. The new Rule Set inherits all the rules of the parent Rule Set and can add new rules and/or override inherited rules. This allows companies to centrally manage core Rule Sets and project teams can then inherit the modifications.<br />
*'''Comparing Rule Sets''': Available from the Command Line Interface, Rule Sets defined on the server can now be compared, generating an HTML report with the differences.<br />
*'''Support for Android''': The Java Rule Set has been enhanced to support android applications. New String Method Filters, String Literal Filters, and String Line Filters have been added to weed out false positive Embedded Strings.<br />
*'''Time Stamps in Console Output and in Show Log''': Time Stamps have been added to the Console output as well as the Show Log HTML page.<br />
*'''Updated RESX Resource File''': The generated RESX Resource File has been updated from version 1.3 to 2.0.<br />
Our '''4.3.1''' release made a few important tuning and performance improvements in the areas of MySQL Client database support, scanning, and the File Inspector.<br />
<br />
==The following lists new features in the Globalyzer 4.3 release==<br />
<br />
*'''Shared Globalyzer Projects''': Globalyzer project and scan configuration (without scan results) can now be shared. Instead of explicitly importing and exporting projects, Globalyzer manages these tasks automatically, enabling team members to work on the same project seamlessly. See the Shared Projects reference page for more information on how to use this new feature.<br />
*'''Import/Merge''': When importing a Globalyzer project that already exists in your workspace, you now have the option to either Overwrite or Merge. Overwrite deletes your existing project before importing the new one; merge combines the imported project with your existing one.<br />
*'''Globalyzer Data Directory Location''': During Client Installation, you are now prompted for the location of the Data Directory, where Globalyzer stores application data and log files as well as the optional HSQLDB database. The default is [userhome]/.globalyzer, but this can be set to another location.<br />
*'''Additional Help on Headless Globalyzer Install''': Login to the Globalyzer Server and click on the Globalyzer Client download link. The Client Installation download page includes instructions on how to install the Globalyzer Client via a script as opposed to a GUI. You'll want to use this when installing Globalyzer to build machines where Globalyzer scanning can be part of the nightly build.<br />
*'''Suggested Rule Sets for Unsupported Languages''': The Create Rule Set reference page provides Rule Set suggestions for currently unsupported languages.<br />
*'''File Inspector Report Line Counts''': Line counts have been added to File Inspector Reports.<br />
<br />
==The following lists new features in the Globalyzer 4.2 release==<br />
<br />
*'''Objective-C Rule Set''': We've added this important rule set to help you internationalize your iOS and other Objective-C applications. In addition to scanning for i18n issues in Objective-C source code, Globalyzer supports string externalization to Objective-C's preferred text resource file type: strings<br />
*'''Ability to Assign Rule Sets to Others''': Though team members can share rule sets, only the rule set owner can made modifications. This feature facilitates passing rule set ownership to another. Just edit the rule set and select a new owner in the Owner dropdown.<br />
*'''Launch Client without First Creating a Rule Set on the Server''': This feature supports the natural process of using Globalyzer: first create a Project, then run File Inspector, then create Rule Sets and Scans.<br />
*'''Create Rule Sets from the Client''': To facilitate rule set creation, Globalyzer now supports the ability to create new rule sets directly from the Client. You may still want do some customization on the Server, but it's now even easier to create that first set of rule sets as you're running the Client, creating your Globalyzer Project and looking at the results of your File Inspection report to determine which rule sets you'll need for scanning your source code.<br />
*'''Additional default Scan Views''': In addition to All Active, there are now default Scan Views for Priority 1, Priority 2, Priority 1 and 2, Ignore, Invalid, ToDo, Filtered, All, and All but Active and Filtered.<br />
*'''Notification of Newer Globalyzer Versions on Client Startup''': On Client startup, a popup displays if there is a newer version of the Client available or if there is a Client/Server version mismatch; the popup includes a link to the latest Client download.<br />
*'''Demo Results displayed based on Priority''': When a demo user executes scans, up to 100 active results are reported. This feature focuses on reporting mostly higher priority issues. It reports 50 Priority 1 issues, 30 Priority 2 issues, 20 Priority 3 issues, 5 Priority 4 issues, and 5 Priority 5 issues.<br />
<br />
==The following lists new features in the Globalyzer 4.1.1 release==<br />
<br />
*'''Additional options when pseudo-localizing your resource files''':<br />
**Pseudo-localize all your base resource files at one time by using the new '''Localize All''' button.<br />
**Use the new '''Start''' and '''End''' fields to specify characters to be displayed before and after each string. This helps you quickly identify layout issues where the full string is not fitting. For example [String]<br />
**You can also specify that each character of the string itself be replaced by an accented character for easier differentiation from English strings. For example '''Šţŕîñg'''<br />
*'''Support for Delphi RC resource file type''': The Delphi language requires its own version of the RC resource file type. Upon string externalization, a .pas file is created and updated, along with the .h and .rc files.<br />
*'''.NET Tutorial''': To accompany our Java tutorial, the .NET tutorial takes your through the basic steps involved in internationalizing a simple .NET Web application.<br />
<br />
==The following lists new features in the Globalyzer 4.1 release==<br />
<br />
*'''Refine your Rule Set from within the Client''': The Globayzer Client now allows you to create both filter and detection rules, rescan your code to see their effects, and update the Rule Set on the server when you are satisfied with the results. This Scan Result driven approach to fine-tuning your Rule Set should help you significantly streamline your scanning and filtering process.<br />
*'''Prioritize your internationalization work''': Globalyzer now prioritizes its locale-sensitive method, general pattern, and static file reference detections (in addition to embedded string detections implemented in version 3.5), helping you focus on the most likely issues first. These priority settings can be customized. You'll see the priority breakdown both on screen and in the many reports that are provided for you to track and manage your progress.<br />
*'''Retain and prioritize strings passed to specified methods''': Rule Sets now include a new detection, called String Method Patterns. This feature allows you to specifically identify methods that are passed strings that would be displayed to the end user. For example, in javascript we have added confirm, in C# Show, and in java JLabel. By identifying these types of methods and configuring them in your Rule Set, you can set the priority for these string detections and ensure that they are addressed during your internationalization process.<br />
*'''Disable Scan Feature''': Scans can now be disabled. Disabled scans can be configured but are not scanned (automatically or manually) and the scan results are not available/displayed. This feature is useful for limiting the amount of rescanning that occurs when configuring scans. The user can focus on one scan, disabling the others.<br />
*'''All resource types now support group mode''': In group mode, externalized strings are grouped by file in the resource file.<br />
*'''All resource types now support comments:''' Comments can be added to resource files and will be preserved during subsequent string externalizations.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_LDAP_Installation&diff=96585Globalyzer Server LDAP Installation2022-09-27T15:43:40Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many large companies use LDAP to manage user information. As new users are hired, they are entered into the company's LDAP system. When users leave the company, they are removed from the company's LDAP system. LDAP is also used to give user's authority to access certain applications within the company. <br />
<br />
Globalyzer can be configured to use your company’s LDAP system. When users log in to Globalyzer, they will enter their LDAP username and LDAP password. If they are authenticated (exist in the LDAP system) and are authorized to use Globalyzer (belong to a Globalyzer group as configured in LDAP), then a Globalyzer account is created with information gathered from LDAP. <br />
<br />
If the user's phone number, title, last name, etc., is modified in LDAP, then the next time the user logs in to Globalyzer, their Globalyzer account information will be updated with the latest information from LDAP. If the user leaves the company and is removed from LDAP, the user can no longer access their Globalyzer account. All Globalyzer user access and information is managed by LDAP.<br />
<br />
== How to Configure LDAP ==<br />
LDAP configuration involves setting the environment variable GZSERVER_LDAP_MODE to true, and configuring GzserverConfig.groovy.<br />
<br />
=== Setting GZSERVER_LDAP_MODE ===<br />
If your server runs on Linux, in the enterprise.sh file, set GZSERVER_LDAP_MODE to true.<br />
<br />
#!/bin/sh<br />
<br />
export GZSERVER_ENTERPRISE_MODE=true<br />
<b>export GZSERVER_LDAP_MODE=true</b><br />
export CATALINA_HOME=/usr/local/tomcat<br />
...<br />
If your server runs on Windows, and you are using the enterprise.bat file to start/stop your server, set GZSERVER_LDAP_MODE to true:<br />
<br />
@echo off<br />
<br />
if "%OS%" == "Windows_NT" setlocal<br />
<br />
set "GZSERVER_ENTERPRISE_MODE=true"<br />
<b>set "GZSERVER_LDAP_MODE=true"</b><br />
set "CATALINA_HOME=C:\apache-tomcat-8.5.23"<br />
...<br />
<br />
If your server runs on Windows and you are running Tomcat as a service, create a new GZSERVER_LDAP_MODE environment variable for the machine, and set it to true.<br />
<br />
=== Configuring GzserverConfig.groovy ===<br />
The bulk of the LDAP configuration takes place in the GzserverConfig.groovy file. There is a section in the file dedicated to LDAP configuration.<br />
<br />
Your company's LDAP stores information for each LDAP user. Map the field names defined in LDAP so that Globalyzer knows how to access the user's first name, last name, etc. <br />
<br />
// ************************ START OF LDAP CONFIGURATION *********************<br />
// **<br />
// ** Uncomment the following 7 gzserver lines and map them to fields in your LDAP<br />
// ** If your LDAP does not have the information per user, leave it as empty string<br />
// ** NOTE: It is required that LDAP contains an email field for each LDAP user<br />
// **<br />
//gzserver.ldap.ctx.firstName = ""<br />
//gzserver.ldap.ctx.lastName = ""<br />
//gzserver.ldap.ctx.email = "mail"<br />
//gzserver.ldap.ctx.phone = ""<br />
//gzserver.ldap.ctx.title = ""<br />
//gzserver.ldap.ctx.country = ""<br />
//gzserver.ldap.ctx.timeZone = ""<br />
<br />
<br />
For example, if the field name for phone is "telephone" in your LDAP, then change the line in GzserverConfig.groovy to this:<br />
<br />
gzserver.ldap.ctx.phone = "telephone"<br />
<br />
If your LDAP does not store a telephone number for LDAP users, then leave the line like this:<br />
<br />
gzserver.ldap.ctx.phone = ""<br />
<br />
The only required field is email. Your company's LDAP must store email information for each user, since the email field is required to create a Globalyzer account.<br />
<br />
In addition to user information, your company's LDAP defines groups and group membership. Group membership is used to determine the applications users have access to, as well as the level of access. For Globalyzer, three new groups should be added to your company's LDAP by your company's LDAP administrator: <br />
* a Globalyzer admin group <br />
* a Globalyzer manager group <br />
* a Globalyzer member group <br />
<br />
Users who have access to Globalyzer will be members of one of these three groups. Your LDAP administrator can choose the group names; below is where you map the groups names defined in LDAP.<br />
<br />
// **<br />
// ** Uncomment the following 3 gzserver lines and map them to groups defined in your LDAP<br />
// ** The LDAP groups represent globalyzer admin, manager, and member access:<br />
// **<br />
//gzserver.ldap.admin.groupName = "GlobalyzerAdmin"<br />
//gzserver.ldap.manager.groupName = "GlobalyzerManager"<br />
//gzserver.ldap.member.groupName = "GlobalyzerMember"<br />
<br />
Configure the message that displays if the user logging in is NOT a member of one of the Globalyzer groups defined above.<br />
<br />
// **<br />
// ** Uncomment the following gzserver line and configure<br />
// ** This text will be displayed to users who are not members of a <br />
// ** Globalyzer group<br />
// **<br />
//gzserver.ldap.noaccess = "You are not authorized to access Globalyzer."<br />
<br />
Next, configure the LDAP server address and then uncomment the providerNames line, as it is already configured correctly.<br />
<br />
// **<br />
// ** Uncomment the following grails line and set to the address of the LDAP server <br />
// **<br />
//grails.plugin.springsecurity.ldap.context.server = 'ldap://localhost:389'<br />
<br />
// **<br />
// ** Uncomment the following grails line; it is already configured properly for LDAP<br />
// **<br />
//grails.plugin.springsecurity.providerNames = ['ldapAuthProvider','anonymousAuthenticationProvider']<br />
<br />
To authenticate LDAP users, Globalyzer connects to your company's LDAP server, logging in via the information provided below. This can be a read only LDAP account and password.<br />
<br />
// **<br />
// ** Uncomment the following two grails lines and set to the DN to authenticate with<br />
// ** Globalyzer; will connect the LDAP server and log in via this account<br />
// ** <b>See the next section for information on how to encrypt the managerPassword</b><br />
// **<br />
//grails.plugin.springsecurity.ldap.context.managerDn = 'cn=read-only-admin,dc=example,dc=com'<br />
//grails.plugin.springsecurity.ldap.context.managerPassword = 'password'<br />
<br />
The rest of the LDAP section of the GzserverConfig.groovy file needs to be configured to perform searches for users and groups. <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure - <br />
// ** The base DN from which the search for group membership should be performed<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The ID of the attribute which contains the role name for a group<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The pattern to be used for the user search. {0} is the user's DN<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** Context name to search in<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The filter expression used in the user search<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
// ************************ END OF LDAP CONFIGURATION *************************<br />
<br />
=== Encrypting the LDAP Password ===<br />
To support LDAP logins, the Globalyzer Server requires an LDAP account that can connect to your LDAP server and perform reads. <br />
As of 6.3, this password may be encrypted, rather that appear in plain text.<br />
To encrypt the password, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file (starting with the 6.3 release).<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
<br />
Plain passwords are still supported and are configured like this:<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'my plain password'<br />
<br />
<br />
=== Configuring a Continuous Integegration User ===<br />
Some companies use one service account to run Lite scans continuously and automatically.<br />
This can put strain on a company's LDAP system, as all calls between a Globalyzer Client and Server require authentication.<br />
Also, a company might not want everyone with access to this service account to be able to log into the Globalyzer Server.<br />
Instead, they want the service user to strictly be a consumer of rule sets.<br />
<br />
To facilitate this, you can define one continuous integration email and password in the GzserverConfig.groovy file.<br />
It would look like this:<br />
<br />
gzserver.ldap.ci_user="ci@company.com"<br />
gzserver.ldap.ci_password="plain text password" <br />
OR<br />
gzserver.ldap.ci_password="ENC(password encoded with globalyzer-encrypt-password.jar)"<br />
<br />
When the server is launched, if the GzserverConfig.groovy file has a ci user defined, Globalyzer will create an acount for that user if it doesn't already exist.<br />
If the user does already exist, Globalyzer will update the password to what is currently specified.<br />
<br />
A Manager Globalyzer account can log into the Server and assign the ci user to a team to access shared rule sets.<br />
<br />
At runtime, when client calls come into the LDAP-configured server, the server first checks for this ci user. If so, the user/password is verified locally in <br />
the Globalyzer database. If it's not the ci user, then an LDAP lookup is performed to authenticate the user.<br />
<br />
Note that the ci user can only be used in Lite. To log into the Server or the Globalyzer Workbench requires an LDAP username and password.<br />
<br />
<br />
== Example LDAP Configuration ==<br />
As an example, let's assume that your LDAP has the following directory structure:<br />
<br />
dc=example, dc=com<br />
ou=Groups<br />
cn=GlobalyzerAdmin<br />
cn=GlobalyzerManager<br />
cn=GlobalyzerMember<br />
cn=SomeOtherGroup<br />
ou=Users<br />
uid=mheilner<br />
uid=lcameron<br />
uid=olibouban<br />
<br />
The configuration for this is shown below:<br />
<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
<br />
== Trouble-Shooting your LDAP Configuration ==<br />
If you are having difficulty logging in to your LDAP-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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does LDAP Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using LDAP? ==<br />
When an LDAP server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, <b>LDAP User</b> and <b>LDAP Password</b> is displayed, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* When an LDAP user initially logs in to the server, a server account will be created if they were authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups)<br />
* If user is NOT authenticated by LDAP, login will fail<br />
* If user is authenticated by LDAP, but not authorized (via group membership), a screen appears saying they are not authorized to access Globalyzer<br />
* On subsequent logins, the user is first authenticated (account is validated against LDAP) and authorized (if Globalyzer group member). Their existing server account is then updated with the latest information in LDAP, 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 LDAP.<br />
<br />
Client Workbench changes:<br />
* Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an LDAP-configured server, a message displays saying that the password cannot be retrieved from an LDAP-configured server<br />
* When LDAP users initially log in to the client (haven't logged in to server yet), a server account will be created for them if they are authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups).<br />
* If user is NOT authenticated by LDAP, login will fail.<br />
* If user is authenticated by LDAP, but not authorized (via group membership), login will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_LDAP_Installation&diff=96584Globalyzer Server LDAP Installation2022-09-26T17:41:12Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many large companies use LDAP to manage user information. As new users are hired, they are entered into the company's LDAP system. When users leave the company, they are removed from the company's LDAP system. LDAP is also used to give user's authority to access certain applications within the company. <br />
<br />
Globalyzer can be configured to use your company’s LDAP system. When users log in to Globalyzer, they will enter their LDAP username and LDAP password. If they are authenticated (exist in the LDAP system) and are authorized to use Globalyzer (belong to a Globalyzer group as configured in LDAP), then a Globalyzer account is created with information gathered from LDAP. <br />
<br />
If the user's phone number, title, last name, etc., is modified in LDAP, then the next time the user logs in to Globalyzer, their Globalyzer account information will be updated with the latest information from LDAP. If the user leaves the company and is removed from LDAP, the user can no longer access their Globalyzer account. All Globalyzer user access and information is managed by LDAP.<br />
<br />
== How to Configure LDAP ==<br />
LDAP configuration involves setting the environment variable GZSERVER_LDAP_MODE to true, and configuring GzserverConfig.groovy.<br />
<br />
=== Setting GZSERVER_LDAP_MODE ===<br />
If your server runs on Linux, in the enterprise.sh file, set GZSERVER_LDAP_MODE to true.<br />
<br />
#!/bin/sh<br />
<br />
export GZSERVER_ENTERPRISE_MODE=true<br />
<b>export GZSERVER_LDAP_MODE=true</b><br />
export CATALINA_HOME=/usr/local/tomcat<br />
...<br />
If your server runs on Windows, and you are using the enterprise.bat file to start/stop your server, set GZSERVER_LDAP_MODE to true:<br />
<br />
@echo off<br />
<br />
if "%OS%" == "Windows_NT" setlocal<br />
<br />
set "GZSERVER_ENTERPRISE_MODE=true"<br />
<b>set "GZSERVER_LDAP_MODE=true"</b><br />
set "CATALINA_HOME=C:\apache-tomcat-8.5.23"<br />
...<br />
<br />
If your server runs on Windows and you are running Tomcat as a service, create a new GZSERVER_LDAP_MODE environment variable for the machine, and set it to true.<br />
<br />
=== Configuring GzserverConfig.groovy ===<br />
The bulk of the LDAP configuration takes place in the GzserverConfig.groovy file. There is a section in the file dedicated to LDAP configuration.<br />
<br />
Your company's LDAP stores information for each LDAP user. Map the field names defined in LDAP so that Globalyzer knows how to access the user's first name, last name, etc. <br />
<br />
// ************************ START OF LDAP CONFIGURATION *********************<br />
// **<br />
// ** Uncomment the following 7 gzserver lines and map them to fields in your LDAP<br />
// ** If your LDAP does not have the information per user, leave it as empty string<br />
// ** NOTE: It is required that LDAP contains an email field for each LDAP user<br />
// **<br />
//gzserver.ldap.ctx.firstName = ""<br />
//gzserver.ldap.ctx.lastName = ""<br />
//gzserver.ldap.ctx.email = "mail"<br />
//gzserver.ldap.ctx.phone = ""<br />
//gzserver.ldap.ctx.title = ""<br />
//gzserver.ldap.ctx.country = ""<br />
//gzserver.ldap.ctx.timeZone = ""<br />
<br />
<br />
For example, if the field name for phone is "telephone" in your LDAP, then change the line in GzserverConfig.groovy to this:<br />
<br />
gzserver.ldap.ctx.phone = "telephone"<br />
<br />
If your LDAP does not store a telephone number for LDAP users, then leave the line like this:<br />
<br />
gzserver.ldap.ctx.phone = ""<br />
<br />
The only required field is email. Your company's LDAP must store email information for each user, since the email field is required to create a Globalyzer account.<br />
<br />
In addition to user information, your company's LDAP defines groups and group membership. Group membership is used to determine the applications users have access to, as well as the level of access. For Globalyzer, three new groups should be added to your company's LDAP by your company's LDAP administrator: <br />
* a Globalyzer admin group <br />
* a Globalyzer manager group <br />
* a Globalyzer member group <br />
<br />
Users who have access to Globalyzer will be members of one of these three groups. Your LDAP administrator can choose the group names; below is where you map the groups names defined in LDAP.<br />
<br />
// **<br />
// ** Uncomment the following 3 gzserver lines and map them to groups defined in your LDAP<br />
// ** The LDAP groups represent globalyzer admin, manager, and member access:<br />
// **<br />
//gzserver.ldap.admin.groupName = "GlobalyzerAdmin"<br />
//gzserver.ldap.manager.groupName = "GlobalyzerManager"<br />
//gzserver.ldap.member.groupName = "GlobalyzerMember"<br />
<br />
Configure the message that displays if the user logging in is NOT a member of one of the Globalyzer groups defined above.<br />
<br />
// **<br />
// ** Uncomment the following gzserver line and configure<br />
// ** This text will be displayed to users who are not members of a <br />
// ** Globalyzer group<br />
// **<br />
//gzserver.ldap.noaccess = "You are not authorized to access Globalyzer."<br />
<br />
Next, configure the LDAP server address and then uncomment the providerNames line, as it is already configured correctly.<br />
<br />
// **<br />
// ** Uncomment the following grails line and set to the address of the LDAP server <br />
// **<br />
//grails.plugin.springsecurity.ldap.context.server = 'ldap://localhost:389'<br />
<br />
// **<br />
// ** Uncomment the following grails line; it is already configured properly for LDAP<br />
// **<br />
//grails.plugin.springsecurity.providerNames = ['ldapAuthProvider','anonymousAuthenticationProvider']<br />
<br />
To authenticate LDAP users, Globalyzer connects to your company's LDAP server, logging in via the information provided below. This can be a read only LDAP account and password.<br />
<br />
// **<br />
// ** Uncomment the following two grails lines and set to the DN to authenticate with<br />
// ** Globalyzer; will connect the LDAP server and log in via this account<br />
// ** <b>See the next section for information on how to encrypt the managerPassword</b><br />
// **<br />
//grails.plugin.springsecurity.ldap.context.managerDn = 'cn=read-only-admin,dc=example,dc=com'<br />
//grails.plugin.springsecurity.ldap.context.managerPassword = 'password'<br />
<br />
The rest of the LDAP section of the GzserverConfig.groovy file needs to be configured to perform searches for users and groups. <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure - <br />
// ** The base DN from which the search for group membership should be performed<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The ID of the attribute which contains the role name for a group<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The pattern to be used for the user search. {0} is the user's DN<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** Context name to search in<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The filter expression used in the user search<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
// ************************ END OF LDAP CONFIGURATION *************************<br />
<br />
=== Encrypting the LDAP Password ===<br />
To support LDAP logins, the Globalyzer Server requires an LDAP account that can connect to your LDAP server and perform reads. <br />
As of 6.3, this password may be encrypted, rather that appear in plain text.<br />
To encrypt the password, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file (starting with the 6.3 release).<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
<br />
Plain passwords are still supported and are configured like this:<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'my plain password'<br />
<br />
<br />
=== Configuring a Continuous Integegration User ===<br />
Some companies use one service account to run Lite scans continuously and automatically.<br />
This can put strain on a company's LDAP system, as all calls between a Globalyzer Client and Server require authentication.<br />
Also, a company might not want everyone with access to this service account to be able to log into the Globalyzer Server.<br />
They want the service user to strictly be a consumer of rule sets.<br />
<br />
To facilitate this, you can define one continuous integration email and password in the GzserverConfig.groovy file.<br />
It would look like this:<br />
<br />
gzserver.ldap.ci_user="ci@company.com"<br />
gzserver.ldap.ci_password="plain text password" <br />
OR<br />
gzserver.ldap.ci_password="ENC(password encoded with globalyzer-encrypt-password.jar)"<br />
<br />
When the server is launched, if The GzserverConfig.groovy file has a ci user defined, Globalyzer will create an acount for that user if it doesn't already exist.<br />
If the user does already exist, Globalyzer will update the password to what is currently specified.<br />
<br />
At runtime, when client calls come into the LDAP-configured server, the server first checks for this ci user. If so, the user/password is verified locally in <br />
the Globalyzer database. If it's not the ci user, then an LDAP lookup is performed to authenticate the user.<br />
<br />
Note that the ci user can only be used in Lite. To log into the Server or the Globalyzer Workbench requires an LDAP username and password.<br />
<br />
<br />
== Example LDAP Configuration ==<br />
As an example, let's assume that your LDAP has the following directory structure:<br />
<br />
dc=example, dc=com<br />
ou=Groups<br />
cn=GlobalyzerAdmin<br />
cn=GlobalyzerManager<br />
cn=GlobalyzerMember<br />
cn=SomeOtherGroup<br />
ou=Users<br />
uid=mheilner<br />
uid=lcameron<br />
uid=olibouban<br />
<br />
The configuration for this is shown below:<br />
<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
<br />
== Trouble-Shooting your LDAP Configuration ==<br />
If you are having difficulty logging in to your LDAP-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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does LDAP Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using LDAP? ==<br />
When an LDAP server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, <b>LDAP User</b> and <b>LDAP Password</b> is displayed, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* When an LDAP user initially logs in to the server, a server account will be created if they were authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups)<br />
* If user is NOT authenticated by LDAP, login will fail<br />
* If user is authenticated by LDAP, but not authorized (via group membership), a screen appears saying they are not authorized to access Globalyzer<br />
* On subsequent logins, the user is first authenticated (account is validated against LDAP) and authorized (if Globalyzer group member). Their existing server account is then updated with the latest information in LDAP, 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 LDAP.<br />
<br />
Client Workbench changes:<br />
* Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an LDAP-configured server, a message displays saying that the password cannot be retrieved from an LDAP-configured server<br />
* When LDAP users initially log in to the client (haven't logged in to server yet), a server account will be created for them if they are authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups).<br />
* If user is NOT authenticated by LDAP, login will fail.<br />
* If user is authenticated by LDAP, but not authorized (via group membership), login will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_LDAP_Installation&diff=96583Globalyzer Server LDAP Installation2022-09-26T17:39:45Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many large companies use LDAP to manage user information. As new users are hired, they are entered into the company's LDAP system. When users leave the company, they are removed from the company's LDAP system. LDAP is also used to give user's authority to access certain applications within the company. <br />
<br />
Globalyzer can be configured to use your company’s LDAP system. When users log in to Globalyzer, they will enter their LDAP username and LDAP password. If they are authenticated (exist in the LDAP system) and are authorized to use Globalyzer (belong to a Globalyzer group as configured in LDAP), then a Globalyzer account is created with information gathered from LDAP. <br />
<br />
If the user's phone number, title, last name, etc., is modified in LDAP, then the next time the user logs in to Globalyzer, their Globalyzer account information will be updated with the latest information from LDAP. If the user leaves the company and is removed from LDAP, the user can no longer access their Globalyzer account. All Globalyzer user access and information is managed by LDAP.<br />
<br />
== How to Configure LDAP ==<br />
LDAP configuration involves setting the environment variable GZSERVER_LDAP_MODE to true, and configuring GzserverConfig.groovy.<br />
<br />
=== Setting GZSERVER_LDAP_MODE ===<br />
If your server runs on Linux, in the enterprise.sh file, set GZSERVER_LDAP_MODE to true.<br />
<br />
#!/bin/sh<br />
<br />
export GZSERVER_ENTERPRISE_MODE=true<br />
<b>export GZSERVER_LDAP_MODE=true</b><br />
export CATALINA_HOME=/usr/local/tomcat<br />
...<br />
If your server runs on Windows, and you are using the enterprise.bat file to start/stop your server, set GZSERVER_LDAP_MODE to true:<br />
<br />
@echo off<br />
<br />
if "%OS%" == "Windows_NT" setlocal<br />
<br />
set "GZSERVER_ENTERPRISE_MODE=true"<br />
<b>set "GZSERVER_LDAP_MODE=true"</b><br />
set "CATALINA_HOME=C:\apache-tomcat-8.5.23"<br />
...<br />
<br />
If your server runs on Windows and you are running Tomcat as a service, create a new GZSERVER_LDAP_MODE environment variable for the machine, and set it to true.<br />
<br />
=== Configuring GzserverConfig.groovy ===<br />
The bulk of the LDAP configuration takes place in the GzserverConfig.groovy file. There is a section in the file dedicated to LDAP configuration.<br />
<br />
Your company's LDAP stores information for each LDAP user. Map the field names defined in LDAP so that Globalyzer knows how to access the user's first name, last name, etc. <br />
<br />
// ************************ START OF LDAP CONFIGURATION *********************<br />
// **<br />
// ** Uncomment the following 7 gzserver lines and map them to fields in your LDAP<br />
// ** If your LDAP does not have the information per user, leave it as empty string<br />
// ** NOTE: It is required that LDAP contains an email field for each LDAP user<br />
// **<br />
//gzserver.ldap.ctx.firstName = ""<br />
//gzserver.ldap.ctx.lastName = ""<br />
//gzserver.ldap.ctx.email = "mail"<br />
//gzserver.ldap.ctx.phone = ""<br />
//gzserver.ldap.ctx.title = ""<br />
//gzserver.ldap.ctx.country = ""<br />
//gzserver.ldap.ctx.timeZone = ""<br />
<br />
<br />
For example, if the field name for phone is "telephone" in your LDAP, then change the line in GzserverConfig.groovy to this:<br />
<br />
gzserver.ldap.ctx.phone = "telephone"<br />
<br />
If your LDAP does not store a telephone number for LDAP users, then leave the line like this:<br />
<br />
gzserver.ldap.ctx.phone = ""<br />
<br />
The only required field is email. Your company's LDAP must store email information for each user, since the email field is required to create a Globalyzer account.<br />
<br />
In addition to user information, your company's LDAP defines groups and group membership. Group membership is used to determine the applications users have access to, as well as the level of access. For Globalyzer, three new groups should be added to your company's LDAP by your company's LDAP administrator: <br />
* a Globalyzer admin group <br />
* a Globalyzer manager group <br />
* a Globalyzer member group <br />
<br />
Users who have access to Globalyzer will be members of one of these three groups. Your LDAP administrator can choose the group names; below is where you map the groups names defined in LDAP.<br />
<br />
// **<br />
// ** Uncomment the following 3 gzserver lines and map them to groups defined in your LDAP<br />
// ** The LDAP groups represent globalyzer admin, manager, and member access:<br />
// **<br />
//gzserver.ldap.admin.groupName = "GlobalyzerAdmin"<br />
//gzserver.ldap.manager.groupName = "GlobalyzerManager"<br />
//gzserver.ldap.member.groupName = "GlobalyzerMember"<br />
<br />
Configure the message that displays if the user logging in is NOT a member of one of the Globalyzer groups defined above.<br />
<br />
// **<br />
// ** Uncomment the following gzserver line and configure<br />
// ** This text will be displayed to users who are not members of a <br />
// ** Globalyzer group<br />
// **<br />
//gzserver.ldap.noaccess = "You are not authorized to access Globalyzer."<br />
<br />
Next, configure the LDAP server address and then uncomment the providerNames line, as it is already configured correctly.<br />
<br />
// **<br />
// ** Uncomment the following grails line and set to the address of the LDAP server <br />
// **<br />
//grails.plugin.springsecurity.ldap.context.server = 'ldap://localhost:389'<br />
<br />
// **<br />
// ** Uncomment the following grails line; it is already configured properly for LDAP<br />
// **<br />
//grails.plugin.springsecurity.providerNames = ['ldapAuthProvider','anonymousAuthenticationProvider']<br />
<br />
To authenticate LDAP users, Globalyzer connects to your company's LDAP server, logging in via the information provided below. This can be a read only LDAP account and password.<br />
<br />
// **<br />
// ** Uncomment the following two grails lines and set to the DN to authenticate with<br />
// ** Globalyzer; will connect the LDAP server and log in via this account<br />
// ** <b>See the next section for information on how to encrypt the managerPassword</b><br />
// **<br />
//grails.plugin.springsecurity.ldap.context.managerDn = 'cn=read-only-admin,dc=example,dc=com'<br />
//grails.plugin.springsecurity.ldap.context.managerPassword = 'password'<br />
<br />
The rest of the LDAP section of the GzserverConfig.groovy file needs to be configured to perform searches for users and groups. <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure - <br />
// ** The base DN from which the search for group membership should be performed<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The ID of the attribute which contains the role name for a group<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The pattern to be used for the user search. {0} is the user's DN<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** Context name to search in<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The filter expression used in the user search<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
// ************************ END OF LDAP CONFIGURATION *************************<br />
<br />
=== Encrypting the LDAP Password ===<br />
To support LDAP logins, the Globalyzer Server requires an LDAP account that can connect to your LDAP server and perform reads. <br />
As of 6.3, this password may be encrypted, rather that appear in plain text.<br />
To encrypt the password, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file (starting with the 6.3 release).<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
<br />
Plain passwords are still supported and are configured like this:<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'my plain password'<br />
<br />
<br />
=== Configuring a Continuous Integegration User ===<br />
Some companies use one service account to run Lite scans continuously and automatically.<br />
This can put strain on a company's LDAP system, as all calls between a Globalyzer Client and Server require authentication.<br />
Also, a company might not want everyone with access to this service account to be able to log into the Globalyzer Server.<br />
They want the service user to strictly be a consumer of rule sets.<br />
<br />
To facilitate this, you can define one continuous integration email and password in the GzserverConfig.groovy file.<br />
It would look like this:<br />
<br />
gzserver.ldap.ci_user="ci@company.com"<br />
gzserver.ldap.ci_password="plain text password" <br />
OR<br />
gzserver.ldap.ci_password="ENC(password encoded with globalyzer-encrypt-password.jar)"<br />
<br />
When the server is launched, if The GzserverConfig.groovy file has a ci user defined, Globalyzer will create an acount for that user if it doesn't already exist.<br />
If the user does already exist, Globalyzer will update the password to what is currently specified.<br />
<br />
At runtime, when client calls come into the LDAP-configured server, the server first checks for this ci user. If so, the user/password is verified locally in <br />
the Globalyzer database. If it's not the ci user, then an LDAP lookup is performed to authenticate the user.<br />
<br />
Note that the ci user can only be used in Lite. To log into the Server or the Globalyzer Workbench requires an LDAP username and password.<br />
<br />
<br />
== Example LDAP Configuration ==<br />
As an example, let's assume that your LDAP has the following directory structure:<br />
<br />
dc=example, dc=com<br />
ou=Groups<br />
cn=GlobalyzerAdmin<br />
cn=GlobalyzerManager<br />
cn=GlobalyzerMember<br />
cn=SomeOtherGroup<br />
ou=Users<br />
uid=mheilner<br />
uid=lcameron<br />
uid=olibouban<br />
<br />
The configuration for this is shown below:<br />
<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
<br />
== Trouble-Shooting your LDAP Configuration ==<br />
If you are having difficulty logging in to your LDAP-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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does LDAP Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using LDAP? ==<br />
When an LDAP server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, <b>LDAP User</b> and <b>LDAP Password</b> is displayed, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* When an LDAP user initially logs in to the server, a server account will be created if they were authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups)<br />
* If user is NOT authenticated by LDAP, login will fail<br />
* If user is authenticated by LDAP, but not authorized (via group membership), a screen appears saying they are not authorized to access Globalyzer<br />
* On subsequent logins, the user is first authenticated (account is validated against LDAP) and authorized (if Globalyzer group member). Their existing server account is then updated with the latest information in LDAP, 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 LDAP.<br />
<br />
Client Workbench changes:<br />
* Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an LDAP-configured server, a message displays saying that the password cannot be retrieved from an LDAP-configured server<br />
* When LDAP users initially log in to the client (haven't logged in to server yet), a server account will be created for them if they are authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups).<br />
* If user is NOT authenticated by LDAP, login will fail.<br />
* If user is authenticated by LDAP, but not authorized (via group membership), login will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_LDAP_Installation&diff=96582Globalyzer Server LDAP Installation2022-09-26T14:58:06Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many large companies use LDAP to manage user information. As new users are hired, they are entered into the company's LDAP system. When users leave the company, they are removed from the company's LDAP system. LDAP is also used to give user's authority to access certain applications within the company. <br />
<br />
Globalyzer can be configured to use your company’s LDAP system. When users log in to Globalyzer, they will enter their LDAP username and LDAP password. If they are authenticated (exist in the LDAP system) and are authorized to use Globalyzer (belong to a Globalyzer group as configured in LDAP), then a Globalyzer account is created with information gathered from LDAP. <br />
<br />
If the user's phone number, title, last name, etc., is modified in LDAP, then the next time the user logs in to Globalyzer, their Globalyzer account information will be updated with the latest information from LDAP. If the user leaves the company and is removed from LDAP, the user can no longer access their Globalyzer account. All Globalyzer user access and information is managed by LDAP.<br />
<br />
== How to Configure LDAP ==<br />
LDAP configuration involves setting the environment variable GZSERVER_LDAP_MODE to true, and configuring GzserverConfig.groovy.<br />
<br />
=== Setting GZSERVER_LDAP_MODE ===<br />
If your server runs on Linux, in the enterprise.sh file, set GZSERVER_LDAP_MODE to true.<br />
<br />
#!/bin/sh<br />
<br />
export GZSERVER_ENTERPRISE_MODE=true<br />
<b>export GZSERVER_LDAP_MODE=true</b><br />
export CATALINA_HOME=/usr/local/tomcat<br />
...<br />
If your server runs on Windows, and you are using the enterprise.bat file to start/stop your server, set GZSERVER_LDAP_MODE to true:<br />
<br />
@echo off<br />
<br />
if "%OS%" == "Windows_NT" setlocal<br />
<br />
set "GZSERVER_ENTERPRISE_MODE=true"<br />
<b>set "GZSERVER_LDAP_MODE=true"</b><br />
set "CATALINA_HOME=C:\apache-tomcat-8.5.23"<br />
...<br />
<br />
If your server runs on Windows and you are running Tomcat as a service, create a new GZSERVER_LDAP_MODE environment variable for the machine, and set it to true.<br />
<br />
=== Configuring GzserverConfig.groovy ===<br />
The bulk of the LDAP configuration takes place in the GzserverConfig.groovy file. There is a section in the file dedicated to LDAP configuration.<br />
<br />
Your company's LDAP stores information for each LDAP user. Map the field names defined in LDAP so that Globalyzer knows how to access the user's first name, last name, etc. <br />
<br />
// ************************ START OF LDAP CONFIGURATION *********************<br />
// **<br />
// ** Uncomment the following 7 gzserver lines and map them to fields in your LDAP<br />
// ** If your LDAP does not have the information per user, leave it as empty string<br />
// ** NOTE: It is required that LDAP contains an email field for each LDAP user<br />
// **<br />
//gzserver.ldap.ctx.firstName = ""<br />
//gzserver.ldap.ctx.lastName = ""<br />
//gzserver.ldap.ctx.email = "mail"<br />
//gzserver.ldap.ctx.phone = ""<br />
//gzserver.ldap.ctx.title = ""<br />
//gzserver.ldap.ctx.country = ""<br />
//gzserver.ldap.ctx.timeZone = ""<br />
<br />
<br />
For example, if the field name for phone is "telephone" in your LDAP, then change the line in GzserverConfig.groovy to this:<br />
<br />
gzserver.ldap.ctx.phone = "telephone"<br />
<br />
If your LDAP does not store a telephone number for LDAP users, then leave the line like this:<br />
<br />
gzserver.ldap.ctx.phone = ""<br />
<br />
The only required field is email. Your company's LDAP must store email information for each user, since the email field is required to create a Globalyzer account.<br />
<br />
In addition to user information, your company's LDAP defines groups and group membership. Group membership is used to determine the applications users have access to, as well as the level of access. For Globalyzer, three new groups should be added to your company's LDAP by your company's LDAP administrator: <br />
* a Globalyzer admin group <br />
* a Globalyzer manager group <br />
* a Globalyzer member group <br />
<br />
Users who have access to Globalyzer will be members of one of these three groups. Your LDAP administrator can choose the group names; below is where you map the groups names defined in LDAP.<br />
<br />
// **<br />
// ** Uncomment the following 3 gzserver lines and map them to groups defined in your LDAP<br />
// ** The LDAP groups represent globalyzer admin, manager, and member access:<br />
// **<br />
//gzserver.ldap.admin.groupName = "GlobalyzerAdmin"<br />
//gzserver.ldap.manager.groupName = "GlobalyzerManager"<br />
//gzserver.ldap.member.groupName = "GlobalyzerMember"<br />
<br />
Configure the message that displays if the user logging in is NOT a member of one of the Globalyzer groups defined above.<br />
<br />
// **<br />
// ** Uncomment the following gzserver line and configure<br />
// ** This text will be displayed to users who are not members of a <br />
// ** Globalyzer group<br />
// **<br />
//gzserver.ldap.noaccess = "You are not authorized to access Globalyzer."<br />
<br />
Next, configure the LDAP server address and then uncomment the providerNames line, as it is already configured correctly.<br />
<br />
// **<br />
// ** Uncomment the following grails line and set to the address of the LDAP server <br />
// **<br />
//grails.plugin.springsecurity.ldap.context.server = 'ldap://localhost:389'<br />
<br />
// **<br />
// ** Uncomment the following grails line; it is already configured properly for LDAP<br />
// **<br />
//grails.plugin.springsecurity.providerNames = ['ldapAuthProvider','anonymousAuthenticationProvider']<br />
<br />
To authenticate LDAP users, Globalyzer connects to your company's LDAP server, logging in via the information provided below. This can be a read only LDAP account and password.<br />
<br />
// **<br />
// ** Uncomment the following two grails lines and set to the DN to authenticate with<br />
// ** Globalyzer; will connect the LDAP server and log in via this account<br />
// ** <b>See the next section for information on how to encrypt the managerPassword</b><br />
// **<br />
//grails.plugin.springsecurity.ldap.context.managerDn = 'cn=read-only-admin,dc=example,dc=com'<br />
//grails.plugin.springsecurity.ldap.context.managerPassword = 'password'<br />
<br />
The rest of the LDAP section of the GzserverConfig.groovy file needs to be configured to perform searches for users and groups. <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure - <br />
// ** The base DN from which the search for group membership should be performed<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The ID of the attribute which contains the role name for a group<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The pattern to be used for the user search. {0} is the user's DN<br />
// **<br />
//grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** Context name to search in<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
<br />
// **<br />
// ** Uncomment the following grails line and configure -<br />
// ** The filter expression used in the user search<br />
// **<br />
//grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
// ************************ END OF LDAP CONFIGURATION *************************<br />
<br />
=== Encrypting the LDAP Password ===<br />
To support LDAP logins, the Globalyzer Server requires an LDAP account that can connect to your LDAP server and perform reads. <br />
As of 6.3, this password may be encrypted, rather that appear in plain text.<br />
To encrypt the password, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file (starting with the 6.3 release).<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
<br />
Plain passwords are still supported and are configured like this:<br />
grails.plugin.springsecurity.ldap.context.managerPassword = 'my plain password'<br />
<br />
<br />
=== Configuring a Continuous Integegration User ===<br />
Some companies would like one service account to run Lite scans continuously and automatically.<br />
This can put strain on a company's LDAP system. Also, a company might not want anyone with access to this service account to log into the Globalyzer Server.<br />
They want this user to strictly be a consumer of rule sets.<br />
<br />
To facilitate this, you can define one continuous integration email and password in the GzserverConfig.groovy file.<br />
It would look like this:<br />
<br />
gzserver.ldap.ci_user="ci@company.com"<br />
gzserver.ldap.ci_password="plain text password" <br />
OR<br />
gzserver.ldap.ci_password="ENC(password encoded with globalyzer-encrypt-password.jar)"<br />
<br />
When the server is launched,<br />
<br />
== Example LDAP Configuration ==<br />
As an example, let's assume that your LDAP has the following directory structure:<br />
<br />
dc=example, dc=com<br />
ou=Groups<br />
cn=GlobalyzerAdmin<br />
cn=GlobalyzerManager<br />
cn=GlobalyzerMember<br />
cn=SomeOtherGroup<br />
ou=Users<br />
uid=mheilner<br />
uid=lcameron<br />
uid=olibouban<br />
<br />
The configuration for this is shown below:<br />
<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchBase = 'ou=Groups,dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.authorities.groupRoleAttribute = 'cn'<br />
grails.plugin.springsecurity.ldap.authorities.groupSearchFilter = 'member={0}' <br />
grails.plugin.springsecurity.ldap.search.base = 'dc=example,dc=com'<br />
grails.plugin.springsecurity.ldap.search.filter = '(uid={0})'<br />
<br />
== Trouble-Shooting your LDAP Configuration ==<br />
If you are having difficulty logging in to your LDAP-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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does LDAP Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using LDAP? ==<br />
When an LDAP server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, <b>LDAP User</b> and <b>LDAP Password</b> is displayed, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* When an LDAP user initially logs in to the server, a server account will be created if they were authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups)<br />
* If user is NOT authenticated by LDAP, login will fail<br />
* If user is authenticated by LDAP, but not authorized (via group membership), a screen appears saying they are not authorized to access Globalyzer<br />
* On subsequent logins, the user is first authenticated (account is validated against LDAP) and authorized (if Globalyzer group member). Their existing server account is then updated with the latest information in LDAP, 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 LDAP.<br />
<br />
Client Workbench changes:<br />
* Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an LDAP-configured server, a message displays saying that the password cannot be retrieved from an LDAP-configured server<br />
* When LDAP users initially log in to the client (haven't logged in to server yet), a server account will be created for them if they are authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups).<br />
* If user is NOT authenticated by LDAP, login will fail.<br />
* If user is authenticated by LDAP, but not authorized (via group membership), login will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Release_Notes&diff=96476Globalyzer Release Notes2022-07-14T16:07:00Z<p>MaryH: /* Globalyzer 6.7.0 Release Notes (June 2022) */</p>
<hr />
<div>For supported versions, please see:<br />
[[Lingoport_Suite_Installation#Supported_Versions]]<br />
==Globalyzer 6.7.0 Release Notes (July 2022)==<br />
The 6.7.0 release includes many system upgrades:<br />
<p><br />
<ul><br />
<li><b>Requires JDK11 to run the Globalyzer Client</b>:<br />
You can download from OpenLogic https://www.openlogic.com/openjdk-downloads<br />
</li><br />
<li><b>Password Encryption Changed</b>:<br />
You will be prompted to log in the first time after installing the Workbench.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.6.0 release==<br />
<p><br />
<ul><br />
<li><b>Go Rule Set:</b><br />
Globalyzer now provides a Go rule set to scan Go language code, and supports Go string externalization to json resource files.<br />
</li><br />
<li><b>Locale-Sensitive Method Priority Updates for JavaScript and CSharp Rule Sets:</b><br />
To streamline your internationalization work, we have updated the default priority settings for JavaScript and C# locale-sensitive methods, setting the methods that are most likely to be issues, to priority 1 or 2.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.5.0 release==<br />
<p><br />
<ul><br />
<li><b>Python Rule Set:</b><br />
Globalyzer now provides a python3 rule set to scan python code, and supports python string externalization to either po or properties resource files.<br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.4.1 release==<br />
The 6.4.1 release involves the Globalyzer Client only (not the Globalyzer Server). This release provides the following enhancements, along with minor bug fixes:<br />
<ul><br />
<li><b>Compressed Prediction Report:</b><br />
The [[ Machine_Learning#Prediction_Reports | prediction report]] for a scan can become quite large. <br />
The generated report is now a zip file, making it easier to check in to version control.<br />
</li><br />
<li><b>Improved Scanning of jsx Files:</b><br />
Jsx files are a mixture of JavaScript and HTML. They are now scanned, by default, by both our JavaScript and HTML rule sets. <br />
Also, HTML scanning of these files has been greatly improved.<br />
</li><br />
<li><b>Improved Scanning of TypeScript Files:</b><br />
The JavaScript rule set has been enhanced to scan ts files. Tsx files (a mixture of TypeScript and HTML), are also scanned by default by both JavaScript and HTML rule sets.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.4.0 release==<br />
<p><br />
<ul><br />
<li><b>Method Statement Filters:</b><br />
These new filters are similar to Method Line Filters, except they apply to a programming language statement, as opposed to a line of code.<br />
If Globalyzer detects a Locale-Sensitive Method, and within the same statement finds a Method Statement Filter,<br />
that method will be excluded from the Locale-Sensitive Method Scan Results.<br />
</li><br />
<li><b>Modified order of Embedded String Filtering and Retention Rules:</b><br />
Prior to this release, the Embedded String scan would first find all strings, then apply all Filtering rules, followed by all Retention rules. <br />
We have found that interleaving Filtering and Retention rules generates better results.<br />
We now apply specific filters and patterns before more general filters and patterns. <br />
For example, a string might be a parameter to a method that is in a line that is part of a statement.<br />
So, if you defined a String Method Pattern to retain an issue, but you have a String Statement Filter that <br />
filters the statement, the issue will ultimately be filtered since the more general, String Statement Filter, is applied last. <br />
</li><br />
</ul><br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.3.0 release==<br />
<ul><br />
<li><b>Concatenation Detection for HTML Strings:</b><br />
HTML strings are sometimes a combination of text, externalized text, server-side code, and in the case of .vm files, variables.<br />
Globalyzer now detects these combinations and will set the priority to C. <br />
Globalyzer also provides a new rule retention for HTML rule sets only, called <b>String Concatenation Patterns</b>,<br />
to find concatenations that would normally be Filtered.<br />
For example, an HTML string which is a series of string externalizations<br />
would not be Active (since the string does not contain text to externalize). <br />
However the string should most likely be externalized as a whole, instead of concatenated parts. <br />
Use a String Concatenation Pattern to find these situations so they can be dealt with properly.<br />
</li><br />
<li><b>Focus on Top Scan Result Issues:</b><br />
Globalyzer has taken a number of steps to help users focus on top issues.<br />
<ol><br />
<li><br />
Defined Scan Views for <b>Top</b>, <b>Most</b>, and <b>All</b> Predicted Issues (select Scan->Refresh Default Scan Views to update existing projects)<br />
</li><br />
<li><br />
Provided shortcut keys to quickly switch among the three views. Ctrl+Shift+1 for Top, Ctrl+Shift+2 for Most, Ctrl+Shift+3 for All.<br />
</li><br />
<li><br />
Provided a new Lite attribute, <b>report-priorities</b>, to specify the priorities to include in the generated report.<br />
</li><br />
</ol><br />
</li><br />
<li><b>Password Encryption for Enterprise Servers:</b><br />
Companies with their own Globalyzer Server must provide some configuration information in the GzserverConfig.groovy file.<br />
This information includes some passwords: the database user password and, if the server is configured to use LDAP, an LDAP password.<br />
These passwords may now be encrypted via a new utility: <b>globalyzer-encrypt-password.jar</b> and the encrypted password may be specified in the<br />
GzserverConfig.groovy file.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.2.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and includes minor bug fixes.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 6.2 release==<br />
<ul><br />
<li><b>Import Lite Project Definition Files:</b><br />
The Workbench can now import Lite Project Definition files, reading from the file to create<br />
a project with scans in the Workbench.<br />
Also, if you are creating an Eclipse project and the base path of the project contains a lingoport/LiteProjectDefinition.xml file, <br />
you may choose to automatically import the file. <br />
In this way you can quickly point to a repo and create the Workbench project from the Lite file in the repo.<br />
</li><br />
<li><b>Support for Android String Externalization:</b><br />
Globalyzer now supports a new resource type, named android, available for both Java and XML scans.<br />
Externalizing to the android resource file writes strings to the file: strings.xml.<br />
</li><br />
<li><b>Rule Set Comparison from the Workbench:</b><br />
From the Workbench, you may now select two rule sets and generate a report comparing them. Previously, this feature was only available from our Command Line Interface.<br />
For example, you can create a default rule set and then extend it, adding/deleting/modifying rules. To see the differences, compare the base rule set with your modified rule set.<br />
</li><br />
<li><b>String Statement Filters for most Rule Set Languages:</b><br />
Originally, String Statement Filters were only implemented for JavaScript. Now, they are available for all languages that support the notion of statements; for example: Java, C#, C++, etc.<br />
If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
</li><br />
<li><b>Improvements regarding Temporary Rules:</b><br />
In the Workbench, you can create temporary rules and scan with them without adding them to rule sets. You may<br />
now see these temporary rules across projects and choose to either delete or submit them. Select Project->Show/Submit Rule Set Filters/Detections menu item in the Workbench.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1.1 release==<br />
<p><br />
This release involves the Globalyzer Client only (not the Globalyzer Server) and provides the following new features:<br />
</p><br />
<ul><br />
<li><b>Introducing Prediction Reports:</b><br />
Prediction Reports are used to save prediction markings, one report per scan. <br />
After marking the predictions for a scan, choose <b>Machine Learning->Export Prediction Report</b> to generate a scan's Prediction Report. <br />
These reports can then be shared with <br />
Globalyzer Lite, other Workbenches, and be reflected in the Dashboard. <br />
Globalyzer Lite will automatically apply the Prediction Report after scanning; <br />
other Workbenches can import the Prediction Report to update their Scan Results with the latest markings; <br />
and the Dashboard, which relies on Globalyzer Lite, will now display the same Scan Results and <br />
predictions shown in the Workbench.<br />
Remember that to speed up your i18n analysis, use <b>Machine Learning->GO!</b> It will use your T/F predictions to make additional predictions.<br />
</li><br />
<li><b>Set Prediction column rather than ToDo, Invalid, and Ignore Status:</b><br><br />
We are deprecating the use of <b>ToDo</b>, <b>Invalid</b>, and <b>Ignore</b> status in favor of<br />
marking the prediction of an issue T/F/P. <br />
<ul><br />
<li>Rather than changing the status of an issue to ToDo, set the prediction to T.</li><br />
<li>Rather than changing the status of an issue to Invalid, set the prediction to F.</li><br />
<li>Rather than changing the status of an issue to Ignore, set the prediction to P (for pending).</li><br />
</ul><br />
After marking your predictions, choose <b>Machine Learning->Export Prediction Report</b><br />
so that your new predictions will be reflected in the Dashboard and can be shared with other<br />
Workbenches.<br />
</li><br />
<li><b>Dashboard False Positive Changes:</b><br />
In our 6.0 release, we added support for synchronizing false positive issues between the <br />
Dashboard and the Workbench using a DFP status.<br />
We are deprecating the DFP status in favor of a DFP prediction value.<br />
Now, <b>Reload Dashboard False Positives</b> will set the prediction value for all<br />
the False Positives on the Dashboard to DFP in the Workbench. Issues with a DFP prediction value can be ignored.<br />
Also, it is no longer necessary to <b>Update to Dashboard as False Positive</b>. Simply mark the prediction F<br />
and export the Prediction Report. Issues marked F will not be displayed on the Dashboard.<br />
To clear a DFP, go to the issue on the Dashboard and make it active again.<br />
</li><br />
<li><b>New Scan Views:</b><br />
We added the following default Scan Views to easily view active issues with various prediction values:<br />
<ul><br />
<li>All Scan Issues - All issues found by scanning, regardless of prediction value</li><br />
<li>All Predicted Active - All issues except those that you, GO!, or the Dashboard<br />
set to False (F, ML False, DFP). These issues are reflected in the Workbench Scan Summary and<br />
in the Dashboard.</li><br />
<li>All Working Active - All issues except those that you have explicitly set to F, or that the<br />
Dashboard set to DFP. Use <b>GO!</b> to speed up the evaluation process.</li><br />
<li>All Undecided - All issues without a set prediction value of T/F/P/DFP.<br />
These are the issues that you still need to evaluate.</li><br />
<li>Prediction T - All active issues with prediction marked T</li><br />
<li>Prediction F - All active issues with prediction marked F</li><br />
<li>Prediction P - All active issues with prediction marked P (pending)</li><br />
<li>Prediction DFP - All active issues with prediction marked DFP</li><br />
</ul><br />
</li><br />
<li><b>Sharing GO! Results:</b><br />
In the Workbench, you automatically generate Machine Learning and<br />
Prediction Report files for a scan <br />
by selecting <b>Machine Learning->GO!</b><br />
These predictions can then be shared with other Workbenches and reflected in the Dashboard.<br />
If you would like to apply existing Machine Learning files to your Scan Results,<br />
you can select <b>Machine Learning->Import Machine Learning</b>. Run <b>GO!</b> whenever you<br />
add or modify T/F/P predictions, so that GO! can make more predictions that are then saved in the<br />
Machine Learning and Prediction Report files.<br />
</li><br />
<li><b>Globalyzer Command Line Client and Machine Learning:</b><br />
When running a scan via the Globalyzer Command Line Client (CLI), you can now apply existing Machine Learning files via a new <b>--machine-learning</b> flag. New code will then be predicted. Note, you still must generate the Machine Learning files for a scan via the Workbench's <b>Machine Learning->GO!</b><br />
</li><br />
<li><b>Scan Reports and Prediction Value:</b><br />
By default, all reports generated from the Workbench, CLI, and Lite will contain only Predicted Active results. This means that results with a prediction value of F, ML False, or DFP will not be reported. XML reports generated from Lite are the exception, and contain results for all prediction values. In the Workbench, you can now configure detailed reports to contain desired prediction values.<br />
</li><br />
</ul><br />
<br />
==The following lists new features in the Globalyzer 6.1 release==<br />
* '''Introducing Machine Learning''': Machine Learning is a powerful new feature that helps users more quickly identify the real issues in their source code. After scanning with Rule Sets in the Workbench, the user marks some active issues as TRUE or FALSE and then invokes Machine Learning to make predictions on the remaining active issues. It may predict ML True (a real issue), ML False (a false issue), or ML NULL (not enough information to make a prediction). This is an iterative process; the user can make corrections by marking more predictions as TRUE or FALSE and re-invoking Machine Learning, until the prediction results are satisfactory. At this point, the issues predicted as TRUE, ML True, or ML NULL are the ones to address. <br />
* '''Company Dictionary''': This feature allows users to add words to their Globalyzer Company's dictionary when scanning. A Company Dictionary is maintained on the Globalyzer Server. Users can upload, download, and view their dictionary contents. To add words to the dictionary, download the dictionary from the Server, modify the dictionary file on your local machine, and upload to the Server. Note that there is one Company Dictionary per company, so all users within the company will see the same dictionary contents. To use the Company Dictionary, download the dictionary from the server and place in your Lingoport directory. When scanning, Globalyzer will include the words from your downloaded dictionary file along with those in the Lingoport Dictionary. <br />
* '''Import Rule Set Enhancement''': You can now export all your rule sets to a single Rule Set Repository file. And then, when importing from this file, you can select just a subset of the Rule Sets to import. <br />
* '''Updated Rule Terminology''': We changed some of our Globalyzer Rule names to be clearer and more consistent: <br />
** String Literal Filters are now String Content Filters<br />
** String Retention Patterns are now String Content Patterns<br />
** String Operand Filters are now String Variable Filters<br />
** String Operand Patterns are now String Variable Patterns<br />
* '''Globalyzer Server requires Tomcat 8.5.x''': The 6.1 release of the Globalyzer Server has been upgraded to use Grails 3, which requires Tomcat 8.5.x (for our Enterprise users).<br />
<br />
==The following lists new features in the Globalyzer 6.0 release==<br />
* '''Support for Local Rule Sets using Lite''': This feature allows scanning to occur without accessing the Globalyzer Server. Rule sets are stored in local files, rather than retrieved from the Server. Use of this feature requires a Globalyzer License to be downloaded from the Server and stored on your local machine. Also note that this feature is only available for Globalyzer Lite. The Workbench, for example, still requires a connection to the Globalyzer Server.<br />
* '''Dashboard False Positive''': A new status has been implemented for Globalyzer, called Dashboard False Positive, or DFP. This status allows the false positives manually ignored in the Workbench (via status changes) to be reflected on the Dashboard. When an issue is set to DFP, the Dashboard is updated and the issue is ignored. The Workbench can also update its list of DFP issues from the Dashboard, allowing the Workbench to ignore false positives found and set by other developers.<br />
* '''Lite Jenkins Plugin''': On-boarding a Globalyzer Lite Jenkins job is made easy by the new Jenkins Plugins.<br />
* '''Security Enhancements''': Several security enhancements have been implemented for the Globalyzer Server. Our password encryption algorithm has been upgraded to use bcrypt, forgot password now performs a password reset rather than retrieval, and we now guard against clickjacking and directory/path traversal attacks. Our version of Tomcat has been upgraded to enable some of these security features.<br />
* '''Report Enhancements''': Previously, generating reports from the Workbench only included issues with Active or Todo status. Now, you can choose the statuses of interest, generating a report of Filtered issues, for instance.<br />
<br />
==The following lists new features in the Globalyzer 5.4 release==<br />
* '''Support for 4-byte UTF-8 Characters''': Updates the MySQL database used by the Globalyzer Server (and the Globalyzer Workbench if installed to use MySQL) to accept 4-byte characters, such as 𡇙. Previously, only supported up to 3-byte UTF-8 characters. Note that your MySQL version must be 5.5.3 or later and MySQL variable settings must be updated to utf8mb4. Instructions are available in Server upgrade documentation as well as Client download and installation directions.<br />
* '''Introducing json as a resource type for JavaScript''': JavaScript embedded strings can now be externalized to json files.<br />
<br />
==The following lists new features in the Globalyzer 5.3 release==<br />
<p><br />
<ul><br />
<li><b>Introducing the Swift Rule Set:</b><br />
We added a new Rule Set to support the Swift programming language. It contains rules for<br />
Embedded Strings, Locale-Sensitive Methods, Static File References, and General Patterns.<br />
</li><br />
<li><b>Enhanced Perl Rule Set:</b><br />
In release 5.2, we added support for Perl Locale-Sensitive Methods, but no content. In this release, <br />
we provide Locale-Sensitive Methods and their corresponding help, in addition to new rules in other categories.<br />
</li><br />
<li><b>Introducing the Globalyzer MVN Plugin:</b><br />
MVN projects can be scanned using our Globalyzer MVN plugin. <br />
The Globalyzer MVN plugin scans your MVN project and generates scan reports to a directory <br />
specified in the pom.xml file. <br />
We ask our MVN customers to install the MVN plugin in a <br />
private MVN repository for your company. Once installed, all developers<br />
can then access the plugin to scan their code.<br />
</li><br />
</ul><br />
</p><br />
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Note:</b> As of 5.3, all Globalyzer Clients are compiled with <b>Java 8</b>;<br />
to run a client, you must have <b>Java 8 (or later)</b> installed on your machine.<br />
</p><br />
<br />
==The following lists new features in the Globalyzer 5.2.1 release ==<br />
This release provides an update to the '''Globalyzer Workbench''' (5.2.1): It is now based on '''Eclipse version 4.6''' (Neon) which runs on '''Java 8'''. The previous version of the Workbench (5.2.0) was based on Eclipse 3.7 and is now deprecated. Workbench 5.2.0 is kept for those clients with previous version of Java, like Java 7. However, we strongly recommend using Workbench 5.2.1 and Java 8.<br />
<br />
==The following lists new features in the Globalyzer 5.2 release==<br />
* '''Introducing Rule Categories''': Rules now have a new Category attribute that allows rules across the rule set to be grouped. Rules can then be quickly enabled/disabled according to category from the Edit Rule Set page.<br />
* '''Enhanced JavaScript Rule Set''' includes jQuery, AngularJS, ReactJS, and NodeJS specific rules: These new rules use the Category attribute to identify the JavaScript library associated with the rule. From the Edit Rule Set page, enable or disable rules for the JavaScript Library Categories to more effectively scan your code. New detection and filter rules have been added to scan code that uses<br />
**'''jQuery'''<br />
**'''AngularJS'''<br />
**'''ReactJS'''<br />
**and '''NodeJS''' libraries.<br />
*New Filter Type for JavaScript Rule Sets - '''String Statement Filters''': If Globalyzer detects a string literal within the statement of a String Statement Filter pattern, that string will be excluded from the Embedded String Scan Results. If multiple statements are on one line, it will only filter the strings found in the filtered statement, and leave other strings on the line detected. If a filtered statement spans multiple lines, it will filter the embedded strings across the multiple code lines.<br />
*Support for '''HTML Tag Libraries''': Globalyzer now supports skipping Tag Library tags during its HTML Embedded String scan, resulting in cleaner scan results. The Tag Library tags are configured in the Ignored HTML Tags rules.<br />
*Locale-Sensitive Method Support for the '''Perl Rule Set''': You can now configure Locale-Sensitive Methods for Perl Rule Sets.<br />
*Support for Mason Files: Globalyzer can now scan Mason Files, which are files containing JavaScript, HTML, and Perl.<br />
<br />
==The following lists new features in the Globalyzer 5.1 release ==<br />
*'''Finer control configuring Locale-Sensitive Methods for Java:''' There are two new fields when configuring Locale-Sensitive Methods for Java, Class or Variable Type and Parameter Type(s) to Filter. If the Class or Variable Type is specified, then only method calls for this class will be detected. If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method will not be detected. <br />
**For example, you can now configure ''toLowerCase'' to be detected only when called via the ''java.lang.String'' class only if a ''java.util.Locale'' parameter has not been provided.<br />
*'''Globalyzer Lite and API Enhancements''': Globalyzer Lite and the API now support setting session and scan options, similar to what is already available in the Globalyzer Workbench. These new options include: <br />
**the location of the data dictionary<br />
**whether or not to filter results against the dictionary<br />
**the scan timeout duration, source file encoding, result types to scan<br />
**comment text.<br />
*'''Globalyzer Lite Login Feature''': You can now set default login information for Globalyzer Lite by creating a '''.globalyzerrc''' file. When processing Project Definition Files, Lite will grab the username/password information from the .globalyzerrc file if it is not provided in the Project Definition File itself.<br />
For more detailed information on 5.1 features, please go to [[Globalyzer 5.1 Features|Globalyzer 5.1 Features]]<br />
<br />
==The following lists new features in the Globalyzer 5.0 release ==<br />
<br />
*'''String Concatenation Detection''': Globalyzer now flags string literals that are part of string concatenations, helping you to easily identify and refactor the concatenation before externalizing strings to resource files. As Globalyzer scans your source code, it sets a detected string's Scan Results priority to the new string concatenation priority 'C' when at least one of the following conditions are true:<br />
**string literal starts or ends with white space<br />
**string literal is preceded or followed by (language specific) concatenation characters<br />
**string literal is a parameter to a Locale-Sensitive Method configured to have priority 0 (the string concatenation priority)<br />
** See [[Globalyzer Concatenation]]<br />
*Finer control when configuring '''String Method Filters and String Method Patterns''' for Java: When configuring String Method Filters and String Method Patterns for your Java Rule Set, you can now optionally include Class or Variable Type(s) to give you finer control over issues being filtered/detected. For example, rather than filtering all strings passed to the method, setName, you can associate a Class name so filtering will only take place when the embedded string is passed to the setName method of the specified Class.<br />
** See [[Globalyzer 5 Java_Rules]]<br />
*Globalyzer Lite Project Definition File '''Generation from Workbench''': Save time setting up Globalyzer Lite by generating your Globalyzer Lite Project Definition File from the Workbench. Create your Workbench Project and then select <code>File->Export->Globalyzer->Export Project Definition (Lite)</code>.<br />
<br />
==The following lists new features in the Globalyzer 4.8.5 release ==<br />
This release focuses on Globalyzer Lite features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports '''navigating to a candidate issue''' within an IDE by '''clicking on the issue''' in the IDE console window. The documentation covers integration within Visual Studio, IntelliJ IDEA, and Eclipse. Integration with numerous other IDEs is also possible.<br />
**'''Build Integration''': Added new command line option to specify the type of console output at the command line.<br />
<br />
==The following lists new features in the Globalyzer 4.8.3 release ==<br />
This release includes bug fixes and these features:<br />
*Improved '''Globalyzer Lite Integration Support''': Globalyzer Lite lets developers check i18n compliance before committing to a source repository.<br />
**'''IDE Internationalization Support''': Globalyzer Lite now supports finding and correcting internationalization issues entirely within an IDE. Our documentation covers integration within '''Visual Studio, IntelliJ IDEA, and Eclipse'''. Integration with numerous '''other IDEs''' is also possible.<br />
**'''Build Integration''': Added new command line options. The project location, scan items, and report directory can now be easily specified at runtime.<br />
<br />
* '''Enhanced Configuration Options''' for Enterprise Servers: <br />
**Enterprise Servers can now configure information and links that display on the Login screen, as well as messages that display for LDAP-configured servers. <br />
**In addition, a default team name may be configured; if specified, newly created users will automatically be assigned to the default team.<br />
<br />
==The following lists new features in the Globalyzer 4.8 release==<br />
<br />
*Introducing '''Globalyzer Lite''': Globalyzer Lite is a lightweight version of the Globalyzer Client. <br />
** It is smaller and faster to install than the Globalyzer Workbench and CLI.<br />
** It requires no external database. <br />
** A '''Project Definition XML''' file allows for the creation of temporary projects and scans, execution of those scans, and generation of corresponding reports. This can be particularly useful in a Continuous Integration model. <br />
** Multiple projects can be processed simultaneously on the same machine.<br />
** '''Note''': This feature requires special licensing. Please contact sales@lingoport.com.<br />
*Globalyzer Server Runs on '''Java 8''': The 4.8 release upgrades the Globalyzer server to run on Java 1.8 (for our Enterprise users). <br />
<br />
'''Note''': Tomcat 7 is now required for deploying the 4.8 Globalyzer Server.<br />
<br />
==The following lists new features in the Globalyzer 4.7 release==<br />
<br />
'''Note''': As of the 4.6 Release, Globalyzer requires Java 1.7. Please make sure that JDK 1.7 is installed on your machine before attempting to install the Globalyzer Client.<br />
<br />
*'''The Globalyzer API''': The Globalyzer API allows you to create Globalyzer projects and scans, execute scans, and generate reports from a java program. This enables projects to be created "on the fly." For example, during code check-in, the check-in process could trigger the execution of a java program that calls the API to scan the source code, enabling timely feedback on its internationalization status. See the Globalyzer API reference page for more information on how to use this new feature.<br />
*'''LDAP for Enterprise Servers''': The Globalyzer Server can be configured to use your company's LDAP system. All Globalyzer user access and information is then managed by LDAP. '''Note''': This feature requires ''special licensing''. Please contact sales@lingoport.com.<br />
*'''Improved Rule Sets''': Updated Globalyzer default rule sets, with specific attention on JavaScript and Objective-C.<br />
<br />
Should you encounter problems or have questions, please email ''support@lingoport.com''.<br />
<br />
==The following lists new features in the Globalyzer 4.6 release==<br />
<br />
*'''Introducing String Operand Filters/Patterns''': This feature (available for all languages except HTML) allows you to filter/retain string literals that are compared with, or assigned to, variables. For languages such as XML, you can use this to filter out string attributes.<br />
*'''Filter Strings used as Array Indices for C#, PHP, and JavaScript''': C#, PHP, and JavaScript support Associative Arrays, where strings can be used to index arrays. String literals used in this manner are not user-facing and should be filtered. This filtering is now performed automatically; there is no Rule Set configuration work required. Note that this has only been implemented for C#, PHP, and JavaScript.<br />
*'''Managers can Assign Ownership of Rule Sets''': Prior to this feature, only Rule Set owners could assign their Rule Sets to another user within the company. Now, managers can assign Rule Sets of team members to other users within the company.<br />
*'''Email False Positive Scan Results to Lingoport''': Feedback from Globalyzer users regarding false positive Scan Results has been invaluable. To help facilitate this feedback, the Workbench now allows the user to select entries in Scan Results and email them to Lingoport via a menu selection. This information will help us further refine our default Rule Sets.<br />
*'''Improved JavaScript Rule Set''': New filters have been added to the JavaScript Rule Set and help for JavaScript Locale-Sensitive Methods has been enhanced.<br />
*'''Secure HTTP''': Globalyzer now supports the additional security of HTTPS for all data that passes between the Client and the globalyzer.com Server.<br />
*'''New version command for the Command Line Client''': The Globalyzer Command Line Client now supports --version and -ver to provide version information for both the Client and the Server.<br />
*'''String Method Filters/Patterns now filter/retain Strings within Nested Methods''': If string literals are passed to a nested method, they will be filtered if the outer method is a String Method Filter, and retained if the outer method is a String Method Pattern.<br />
*'''Reason Field in Scan Results more Descriptive for Embedded Strings''': In addition to displaying the pattern of the rule (that either filtered or retained the Embedded String), the Reason field now includes "Literal", "Line", "Method", or "Operand", to indicate the type of the rule.<br />
*'''Reorganization of Reference Section Help''': The Reference Section Help has been organized into Command Line, Server, and Workbench Reference sections.<br />
<br />
==The following lists new features in the Globalyzer 4.5 release==<br />
<br />
*'''Rule Set Inheritance''': Rule Sets now support inheritance! A Rule Set can be created to extend an existing Rule Set. The new Rule Set inherits all the rules of the parent Rule Set and can add new rules and/or override inherited rules. This allows companies to centrally manage core Rule Sets and project teams can then inherit the modifications.<br />
*'''Comparing Rule Sets''': Available from the Command Line Interface, Rule Sets defined on the server can now be compared, generating an HTML report with the differences.<br />
*'''Support for Android''': The Java Rule Set has been enhanced to support android applications. New String Method Filters, String Literal Filters, and String Line Filters have been added to weed out false positive Embedded Strings.<br />
*'''Time Stamps in Console Output and in Show Log''': Time Stamps have been added to the Console output as well as the Show Log HTML page.<br />
*'''Updated RESX Resource File''': The generated RESX Resource File has been updated from version 1.3 to 2.0.<br />
Our '''4.3.1''' release made a few important tuning and performance improvements in the areas of MySQL Client database support, scanning, and the File Inspector.<br />
<br />
==The following lists new features in the Globalyzer 4.3 release==<br />
<br />
*'''Shared Globalyzer Projects''': Globalyzer project and scan configuration (without scan results) can now be shared. Instead of explicitly importing and exporting projects, Globalyzer manages these tasks automatically, enabling team members to work on the same project seamlessly. See the Shared Projects reference page for more information on how to use this new feature.<br />
*'''Import/Merge''': When importing a Globalyzer project that already exists in your workspace, you now have the option to either Overwrite or Merge. Overwrite deletes your existing project before importing the new one; merge combines the imported project with your existing one.<br />
*'''Globalyzer Data Directory Location''': During Client Installation, you are now prompted for the location of the Data Directory, where Globalyzer stores application data and log files as well as the optional HSQLDB database. The default is [userhome]/.globalyzer, but this can be set to another location.<br />
*'''Additional Help on Headless Globalyzer Install''': Login to the Globalyzer Server and click on the Globalyzer Client download link. The Client Installation download page includes instructions on how to install the Globalyzer Client via a script as opposed to a GUI. You'll want to use this when installing Globalyzer to build machines where Globalyzer scanning can be part of the nightly build.<br />
*'''Suggested Rule Sets for Unsupported Languages''': The Create Rule Set reference page provides Rule Set suggestions for currently unsupported languages.<br />
*'''File Inspector Report Line Counts''': Line counts have been added to File Inspector Reports.<br />
<br />
==The following lists new features in the Globalyzer 4.2 release==<br />
<br />
*'''Objective-C Rule Set''': We've added this important rule set to help you internationalize your iOS and other Objective-C applications. In addition to scanning for i18n issues in Objective-C source code, Globalyzer supports string externalization to Objective-C's preferred text resource file type: strings<br />
*'''Ability to Assign Rule Sets to Others''': Though team members can share rule sets, only the rule set owner can made modifications. This feature facilitates passing rule set ownership to another. Just edit the rule set and select a new owner in the Owner dropdown.<br />
*'''Launch Client without First Creating a Rule Set on the Server''': This feature supports the natural process of using Globalyzer: first create a Project, then run File Inspector, then create Rule Sets and Scans.<br />
*'''Create Rule Sets from the Client''': To facilitate rule set creation, Globalyzer now supports the ability to create new rule sets directly from the Client. You may still want do some customization on the Server, but it's now even easier to create that first set of rule sets as you're running the Client, creating your Globalyzer Project and looking at the results of your File Inspection report to determine which rule sets you'll need for scanning your source code.<br />
*'''Additional default Scan Views''': In addition to All Active, there are now default Scan Views for Priority 1, Priority 2, Priority 1 and 2, Ignore, Invalid, ToDo, Filtered, All, and All but Active and Filtered.<br />
*'''Notification of Newer Globalyzer Versions on Client Startup''': On Client startup, a popup displays if there is a newer version of the Client available or if there is a Client/Server version mismatch; the popup includes a link to the latest Client download.<br />
*'''Demo Results displayed based on Priority''': When a demo user executes scans, up to 100 active results are reported. This feature focuses on reporting mostly higher priority issues. It reports 50 Priority 1 issues, 30 Priority 2 issues, 20 Priority 3 issues, 5 Priority 4 issues, and 5 Priority 5 issues.<br />
<br />
==The following lists new features in the Globalyzer 4.1.1 release==<br />
<br />
*'''Additional options when pseudo-localizing your resource files''':<br />
**Pseudo-localize all your base resource files at one time by using the new '''Localize All''' button.<br />
**Use the new '''Start''' and '''End''' fields to specify characters to be displayed before and after each string. This helps you quickly identify layout issues where the full string is not fitting. For example [String]<br />
**You can also specify that each character of the string itself be replaced by an accented character for easier differentiation from English strings. For example '''Šţŕîñg'''<br />
*'''Support for Delphi RC resource file type''': The Delphi language requires its own version of the RC resource file type. Upon string externalization, a .pas file is created and updated, along with the .h and .rc files.<br />
*'''.NET Tutorial''': To accompany our Java tutorial, the .NET tutorial takes your through the basic steps involved in internationalizing a simple .NET Web application.<br />
<br />
==The following lists new features in the Globalyzer 4.1 release==<br />
<br />
*'''Refine your Rule Set from within the Client''': The Globayzer Client now allows you to create both filter and detection rules, rescan your code to see their effects, and update the Rule Set on the server when you are satisfied with the results. This Scan Result driven approach to fine-tuning your Rule Set should help you significantly streamline your scanning and filtering process.<br />
*'''Prioritize your internationalization work''': Globalyzer now prioritizes its locale-sensitive method, general pattern, and static file reference detections (in addition to embedded string detections implemented in version 3.5), helping you focus on the most likely issues first. These priority settings can be customized. You'll see the priority breakdown both on screen and in the many reports that are provided for you to track and manage your progress.<br />
*'''Retain and prioritize strings passed to specified methods''': Rule Sets now include a new detection, called String Method Patterns. This feature allows you to specifically identify methods that are passed strings that would be displayed to the end user. For example, in javascript we have added confirm, in C# Show, and in java JLabel. By identifying these types of methods and configuring them in your Rule Set, you can set the priority for these string detections and ensure that they are addressed during your internationalization process.<br />
*'''Disable Scan Feature''': Scans can now be disabled. Disabled scans can be configured but are not scanned (automatically or manually) and the scan results are not available/displayed. This feature is useful for limiting the amount of rescanning that occurs when configuring scans. The user can focus on one scan, disabling the others.<br />
*'''All resource types now support group mode''': In group mode, externalized strings are grouped by file in the resource file.<br />
*'''All resource types now support comments:''' Comments can be added to resource files and will be preserved during subsequent string externalizations.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=96472Globalyzer Server SSO Installation2022-06-22T21:55:26Z<p>MaryH: /* Overview */</p>
<hr />
<div>== Overview ==<br />
Many companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/saml/SSO, for example https://saml.lingoport.net/gzserver/saml/SSO<br />
* Audience URI: whatever you put here must match the entity id you put in the sp.xml file, for example, GlobalyzerServer<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=96471Globalyzer Server SSO Installation2022-06-22T21:44:55Z<p>MaryH: </p>
<hr />
<div>== Overview ==<br />
Many large companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/saml/SSO, for example https://saml.lingoport.net/gzserver/saml/SSO<br />
* Audience URI: whatever you put here must match the entity id you put in the sp.xml file, for example, GlobalyzerServer<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=96470Globalyzer Server SSO Installation2022-06-22T21:38:46Z<p>MaryH: /* How Does SSO Work on Globalyzer Login? */</p>
<hr />
<div>== Overview ==<br />
Many large companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/saml/SSO, for example https://saml.lingoport.net/gzserver/saml/SSO<br />
* Audience URI: whatever you put here must match the entity id you put in the sp.xml file, for example, GlobalyzerServer<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
<br />
<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=96469Globalyzer Server SSO Installation2022-06-22T21:37:14Z<p>MaryH: /* What Differences Will I see Using LDAP? */</p>
<hr />
<div>== Overview ==<br />
Many large companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/saml/SSO, for example https://saml.lingoport.net/gzserver/saml/SSO<br />
* Audience URI: whatever you put here must match the entity id you put in the sp.xml file, for example, GlobalyzerServer<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
<br />
<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does SSO Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using SSO? ==<br />
When an SSO server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, an SSO login button displays, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* 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)<br />
* If user is NOT authenticated or authorized, login will fail<br />
* 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.<br />
<br />
Client Workbench changes:<br />
* 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<br />
<br />
Client access to an SSO-configured Server:<br />
* To run a Globalyzer Client (Workbench, Lite) against an SSO-configured Server, you need to generate a token from the Server (click on the <b>download Globalyzer Client here</b> 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.<br />
* Tokens expire in 90 days, but the number of days is configurable in the GzserverConfig.groovy file.<br />
* Tokens may be auto renewed by logging into the server. This feature is configurable in GzserverConfig.groovy.<br />
* Attempting to log in with expired tokens will fail.</div>MaryHhttp://wiki.lingoport.com/index.php?title=Globalyzer_Server_SSO_Installation&diff=96468Globalyzer Server SSO Installation2022-06-22T21:19:56Z<p>MaryH: /* Encrypting the LDAP Password */</p>
<hr />
<div>== Overview ==<br />
Many large companies use SAML SSO with an Identity Provider to manage users and access to applications.<br />
To integrate Globalyzer with SAML SSO, first, the Identity Provider must be configured to allow access to Globalyzer.<br />
Then, Globalyzer must be configured for SSO. The result is three key files referenced from GzserverConfig.groovy<br />
# a keystore that contains the identity provider certificate and a key<br />
# the idp.xml file that describes the identity provider (Okta in our example)<br />
# the sp.xml file that describes the service provider (our Globalyzer application)<br />
<br />
== Configure the Identity Provider ==<br />
We will be using Okta as the Identity Provider in order to illustrate how to configure Globalyzer.<br />
<br />
=== Set up Okta Developer Account ===<br />
* https://developer.okta.com/signup/<br />
* Enter <b>Admin</b> mode<br />
<br />
=== Create Globalyzer Groups/People ===<br />
* Click <b>Directory->Groups</b> on left<br />
* Create <b>Globalyzer Admin</b> group<br />
* Create <b>Globalyzer Manager</b> group<br />
* Create <b>Globalyzer Member</b> group<br />
* Choose <b>Directory->People</b> on left<br />
* Add accounts and assign to appropriate Globalyzer Groups<br />
<br />
=== Create Okta Application ===<br />
* Click <b>Applications->Applications</b> on the left.<br />
* Click <b>Create App Integration</b><br />
* Choose <b>SAML 2.0</b> and then Next<br />
* Give your app a name and click Next<br />
* Single sign on URL: <your server machine>/gzserver/saml/SSO, for example https://saml.lingoport.net/gzserver/saml/SSO<br />
* Audience URI: whatever you put here must match the entity id you put in the sp.xml file, for example, GlobalyzerServer<br />
* Attributes Section: enter in the following:<br />
First Name, Unspecified, user.firstName<br />
Last Name, Unspecified, user.lastName<br />
Email, Unspecified, user.email<br />
* Groups Section: enter in the following:<br />
memberOf, Unspecified, Contains, Globalyzer<br />
* Select <b>I'm an Okta customer adding an internal app</b><br />
* Check <b>This is an internal app that we have created</b><br />
* Go to <b>Assignments</b> tab<br />
* Assign the three Globalyzer groups to your app<br />
<br />
=== Download Artifacts ===<br />
* Go to <b>Sign On</b> tab of your app<br />
* Click <b>View SAML setup instructions</b><br />
* Download certificate<br />
* Copy IDP Metadata to a file named idp.xml<br />
<br />
== Generate Keys and Keystore ==<br />
* Generate key and keystore:<br />
keytool -genkey -alias samlkey -keyalg RSA -keystore saml-keystore.jks<br />
* Accept Identity Provider Certficate<br />
keytool -import -alias okta -keystore saml-keystore.jsk -file <certificate you downloaded from okta><br />
<br />
== Generate sp.xml ==<br />
* Create a file named sp.xml with the following contents <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <b>entityID</b>="GlobalyzerServer"><br />
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br />
<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" <b>Location</b>="https://saml.lingoport.net/gzserver/login/auth?disco=true"/> <br />
</md:Extensions><md:KeyDescriptor use="signing"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo></md:KeyDescriptor><br />
<md:KeyDescriptor use="encryption"><br />
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><br />
<ds:X509Certificate><b>CERTIFICATE</b></ds:X509Certificate><br />
</ds:X509Data></ds:KeyInfo><br />
</md:KeyDescriptor><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SingleLogout"/><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <br />
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="0" isDefault="true"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="1" isDefault="false"/><br />
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" <b>Location</b>="https://saml.lingoport.net/gzserver/saml/SSO" index="2" isDefault="false"/><br />
</md:SPSSODescriptor><br />
</md:EntityDescriptor><br />
<br />
* Modify <b>entityId</b> to match what you specified as <b>Audience</b> in your Okta app<br />
* Replace the two <b>CERTIFICATEs</b> with the certificate you downloaded from Okta. Open the file and grab the lines between BEGIN CERTIFICATE and END CERTIFICATE in the downloaded file.<br />
* Update the various <b>Locations</b> to be the machine your Globalyzer Server is running on ... keeping the /gzserver/saml/SSO or /gzserver/saml/SingleLogout endings<br />
<br />
== Configure GzserverConfig.groovy ==<br />
<br />
* Copy saml-keystore.jks, sp.xml, and idp.xml files to a specific location on the machine running the Globalyzer Server.<br />
* Add and configure the following lines to GzserverConfig.groovy:<br />
<br />
// tell Globalyzer and the Plugin to use saml<br />
gzserver.saml.mode = true<br />
grails.plugin.springsecurity.saml.active = true<br />
grails.plugin.springsecurity.providerNames = ['samlAuthenticationProvider','anonymousAuthenticationProvider']<br />
<br />
// keystore configuration<br />
// assuming you created a keystore named saml-keystore.jks and a key named samlkey ...<br />
grails.plugin.springsecurity.saml.keyManager.storeFile = "file:/path/to/saml-keystore.jks"<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'saml.keystore.pw'<br />
grails.plugin.springsecurity.saml.keyManager.passwords = [samlkey:'saml.keystore.pw']<br />
grails.plugin.springsecurity.saml.keyManager.defaultKey = 'samlkey'<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.signingKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.encryptionKey = 'samlkey';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.tlsKey = 'samlkey';<br />
<br />
// leave as is if created okta app as specified above<br />
grails.plugin.springsecurity.saml.userGroupAttribute = 'memberOf'<br />
grails.plugin.springsecurity.saml.userAttributeMappings = ['username' : 'Email', 'firstName': 'First Name', 'lastName' : 'Last Name']<br />
grails.plugin.springsecurity.saml.userGroupToRoleMapping = ['ROLE_ADMIN': 'Globalyzer Admin', 'ROLE_MANAGER': 'Globalyzer Manager', 'ROLE_USER': 'Globalyzer Member']<br />
<br />
// idp configuration<br />
grails.plugin.springsecurity.saml.metadata.defaultIdp = 'entity id found in idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.idp.file = '/path/to/idp.xml'<br />
grails.plugin.springsecurity.saml.metadata.providers = ['samlkey':'/path/to/idp.xml']<br />
<br />
// sp configuration<br />
grails.plugin.springsecurity.saml.metadata.sp.file = "/path/to/sp.xml"<br />
grails.plugin.springsecurity.saml.metadata.sp.alias = "entity id found in sp.xml file"<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.alias = 'entity id found in sp.xml file';<br />
grails.plugin.springsecurity.saml.metadata.sp.defaults.entityId = 'entity id found in sp.xml file'<br />
<br />
// http or https along with your machine name<br />
grails.plugin.springsecurity.saml.scheme = "https"<br />
grails.plugin.springsecurity.saml.serverName = "saml.lingoport.net"<br />
<br />
// true if want token to auto renew when user logs into server<br />
grails.plugin.springsecurity.saml.autoRenewToken = true<br />
<br />
// specify number of days until token expires<br />
grails.plugin.springsecurity.saml.renewTokenDays = 90<br />
<br />
<br />
<br />
<br />
=== Encrypting SSO Passwords ===<br />
To support SSO logins, there are some passwords required in the GzserverConfig.groovy file:<br />
* grails.plugin.springsecurity.saml.keyManager.storePass = 'my plain password'<br />
* grails.plugin.springsecurity.saml.passwords = [samlkey:'my plain password']<br />
<br />
You may encrypt these passwords, rather than having them appear in the config file as plain text.<br />
<br />
To encrypt the passwords, you must use the <b>globalyzer-encrypt-password.jar</b> that is available in the Globalyzer-Server.zip file.<br />
<br />
Run the jar to generate an encrypted password:<br />
$ java -jar globalyzer-encrypt-password.jar -in "my plain password"<br />
Encrypted Password: CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=<br />
<br />
Then place the generated password in the GzserverConfig.groovy file within ENC():<br />
grails.plugin.springsecurity.saml.keyManager.storePass = 'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)'<br />
grails.plugin.springsecurity.saml.passwords = [samlkey:'ENC(CLCjzYV02uZaWDTDkcvK65BndTfUlH5leL00vsgWkmY=)']<br />
<br />
== Trouble-Shooting your SSO Configuration ==<br />
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. <br />
<br />
To do this, place the logback-debug.groovy file (delivered in the Globalyzer Server zip file) to a location on your server. Then add <b>-Dlogging.config</b> to your JAVA_OPTS in your enterprise.sh/bat script to use this file. <br />
<br />
For example, the modified enterprise.bat would look like this:<br />
<br />
<code>set "JAVA_OPTS=-Xms256m -Xmx1600m -Dstringchararrayaccessor.disabled=true -Dlogging.config=C:\path\to\logback-debug.groovy"</code><br />
<br />
Then stop and start your Globalyzer Server to incorporate the changes. You should now see more information written to the gzserver.log file.<br />
<br />
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.<br />
<br />
== How Does SSO Work on Globalyzer Login? ==<br />
When logging in to the Globalyzer Server or Client, the user will enter in their LDAP username and password. Globalyzer logs in to the LDAP server using the configured <code>managerDN</code> and <code>managerPassword</code>. A search is performed to authenticate the LDAP user as entered on the login screen. The search for this user will begin at the configured <code>ldap.search.base</code> and use the configured <code>ldap.search.filter</code>. If the user is not found, or the password is incorrect, the login will fail. <br />
<br />
If the user is a valid LDAP user, then a search for the groups the user belongs to is performed. This group search begins at the configured <code>groupSearchBase</code>. Groups are identified in LDAP by the configured <code>groupRoleAttribute</code>. It uses the configured <code>groupSearchFilter</code> to determine if the found user is a member of the group. Users may be members of several groups across LDAP, but only one Globalyzer group.<br />
<br />
If logging into the server, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups (admin, manager, or member), the user will be logged in, but won't be able to perform any actions, since not authorized to do so.<br />
<br />
If logging into the client, and the user is authenticated (user is a valid LDAP user) but the user does not belong to one of the three Globalyzer groups, login will fail.<br />
<br />
On initial login, if the user is authenticated (user is valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), a Globalyzer account is created at the appropriate access level.<br />
<br />
On subsequent logins, if the user is authenticated (user is a valid LDAP user) and authorized (user belongs to one of the three Globalyzer groups), the existing server account is then updated with the latest information in LDAP, except for the level of access. If the user was authorized to be a Globalyzer Manager when the account was created, the user will always be a Globalyzer Manager. Switching the user to a different access level requires that the Globalyzer account be deleted (by a Globalyzer Manager or Member), and then on login, the Globalyzer account will be recreated at the current access level as configured in LDAP.<br />
<br />
== What Differences Will I see Using LDAP? ==<br />
When an LDAP server has been successfully configured and launched, you will see these changes.<br />
<br />
Server changes:<br />
* On server login screen, <b>LDAP User</b> and <b>LDAP Password</b> is displayed, rather than Email and Password<br />
* On server login screen, <b>Forgot Password</b> link is removed<br />
* Admin users can no longer create other Admins, Managers, or Members<br />
* Manager users can no longer create other Managers or Members<br />
* No users can edit their profile<br />
* When an LDAP user initially logs in to the server, a server account will be created if they were authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups)<br />
* If user is NOT authenticated by LDAP, login will fail<br />
* If user is authenticated by LDAP, but not authorized (via group membership), a screen appears saying they are not authorized to access Globalyzer<br />
* On subsequent logins, the user is first authenticated (account is validated against LDAP) and authorized (if Globalyzer group member). Their existing server account is then updated with the latest information in LDAP, 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 LDAP.<br />
<br />
Client Workbench changes:<br />
* Forgot Password link still displays (since clients can connect to various servers) but if they are connected to an LDAP-configured server, a message displays saying that the password cannot be retrieved from an LDAP-configured server<br />
* When LDAP users initially log in to the client (haven't logged in to server yet), a server account will be created for them if they are authenticated by LDAP and authorized (by belonging to one of the three Globalyzer groups).<br />
* If user is NOT authenticated by LDAP, login will fail.<br />
* If user is authenticated by LDAP, but not authorized (via group membership), login will fail.</div>MaryH