Third-Party Authentication

Third-party authentication enables users to log in to SGD if they have been authenticated by an external mechanism.

If you are using the SGD webtop, the only form of third-party authentication you can use is web server authentication. If you develop your own webtop applications using SGD web services, you can use any third-party authentication mechanism.

Third-party authentication is disabled by default.

This section includes the following topics:

• How Third-Party Authentication Works

• Setting Up Third-Party Authentication

• How to Enable Third-Party Authentication

• SGD Administrators and Third-Party Authentication

• Trusted Users and Third-Party Authentication

How Third-Party Authentication Works

The user types in a user name and password directly to the external mechanism, typically using a web browser’s authentication dialog.

Third-party authentication is based on trust. SGD trusts that the third-party mechanism has authenticated the user correctly and so they are authenticated to SGD.

Next SGD performs a search to establish the user identity and user profile. The following search methods can be used:

• Search Local Repository

• Search LDAP Repository

• Use Default Third-Party Identity

If more than one search method is enabled, the methods are tried in the order they are listed above. The first matching user identity found is used. The search methods are described in the following sections.

If the searches do not produce a match, SGD cannot establish an identity for the user and the user cannot log in. If you are using the SGD webtop, the standard login page displays so that the user can log in using system authentication.

Search Local Repository

The Search Local Repository method searches the local repository for a user profile with a Name attribute that matches the user’s third-party user name. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute. If no user profile is found, the next search method is tried.

User Identity and User Profile

If a user profile is found, that object is used for the user identity and user profile. In the SGD datastore, the user identity is in the Local namespace. In the Administration Console, the text “(Local)” is displayed next to the user identity. On the command line, the user identity is located in .../_ens.

Search LDAP Repository

The Search LDAP Repository method searches an LDAP directory for an LDAP object with an attribute that matches the user name typed by the user. By default, SGD searches the following attributes:

• cn

• uid

• mail

If an LDAP object is found, the password typed by the user is checked against the LDAP object. If the authentication fails, the next authentication mechanism is tried.

If an LDAP object is not found, the next search method is tried.

User Identity and User Profile

The user identity is the DN of the user’s LDAP object. In the SGD datastore, the user identity is in the LDAP namespace. In the Administration Console, the text “(LDAP)” is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/ldapcache.

Next SGD searches for the user profile. When searching for the user profile, you can specify Use Default LDAP Profile or Use Closest Matching LDAP Profile. Use Default LDAP Profile is the default.

If Use Default LDAP Profile is selected, the profile object o=System Objects/cn=LDAP Profile is used for the user profile.

If Use Closest Matching LDAP Profile is selected, SGD establishes the user profile by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:

• A user profile with the same name as the user’s LDAP object.

  For example, if the LDAP object is cn=Emma Rald,cn=Sales,dc=example,dc=com, SGD searches the local repository for dc=com/dc=example/cn=Sales/cn=Emma Rald.

• A user profile in the same organizational unit as the user’s LDAP object but with the name cn=LDAP Profile.

  For example, dc=com/dc=example/cn=Sales/cn=LDAP Profile.

• A user profile in any parent organizational unit with the name cn=LDAP Profile.

  For example, dc=com/dc=example/cn=LDAP Profile.

If there is no match, the profile object o=System Objects/cn=LDAP Profile is used for the user profile.

Use Default Third-Party Identity

The Use Default Third-Party Identity method does not perform a search.

User Identity and User Profile

The user identity is the third-party user name. In the SGD datastore, the user identity is in the Third–party namespace. In the Administration Console, the text “(3rd party)” is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/thirdparty.

The profile object System Objects/Third Party Profile is always used for the user profile.

Setting Up Third-Party Authentication

Setting up third–party authentication involves the following configuration steps:

1. (Optional) Prepare to use LDAP directories.

   Third–party authentication can be configured to search an LDAP directory to establish users’ identities.

   Check that you are using a supported LDAP directory, see Supported LDAP Directories.

   Additional configuration might be required to use SGD with your LDAP directory, see Preparing for LDAP Authentication.

   For organizations with complex LDAP deployments, use service objects to manage and tune your LDAP configuration. See Using Service Objects.

2. Enable third–party authentication.

   See How to Enable Third-Party Authentication.

   By default, SGD Administrators cannot log in to SGD when third–party authentication is enabled, see SGD Administrators and Third-Party Authentication.

3. Enable a third–party authentication mechanism.

   The most common authentication mechanism used with third–party authentication is web server authentication.

How to Enable Third-Party Authentication

1. In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.

   Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.

2. On the Third-Party/System Authentication step, select the Third-Party Authentication check box.

3. On the Third-Party Authentication - User Identity and Profile step, select the check box for one or more search methods for finding the user identity.

   For details on how the search methods work, see How Third-Party Authentication Works.

   If the Search LDAP Repository check box is selected, select an option for finding the LDAP user profile.

4. (Optional)

   On the LDAP Repository Details step, configure the LDAP directory details.

   The LDAP Repository Details step only displays if an LDAP search method is selected in Step 3.

   1. For Repository Type, select the LDAP option.

      Select this option even if you are using a Microsoft Active Directory server for LDAP authentication. The Active Directory option enables Active Directory authentication, see Active Directory Authentication.

   2. In the URLs field, type the URL of one or more LDAP directory servers.

      For example, ldap://melbourne.example.com.

      If you type more than one URL, separate each URL with a semicolon (;).

      SGD uses the URLs in the order they are listed. If the first LDAP directory server in the list is unavailable, the next one is tried.

      To use secure connections to LDAP directory servers, use an ldaps:// URL.

      The URLS must all be of the same type, either ldap:// or ldaps://. You cannot use a mixture of ldap:// and ldaps:// URLs.

      If the LDAP directory uses a non-standard port, specify the port number as part of the URL, for example ldap://melbourne.example.com:5678. Otherwise the port number can be omitted.

      You can specify a DN to use as the search base, for example ldap://melbourne.example.com/dc=example,dc=com. This specifies the part of the LDAP directory used to search for the user identity.

   3. Type the details of an LDAP user in the User Name and Password fields.

      The user name must be the DN of the user, for example cn=sgd-user,cn=Users,dc=example,dc=com. This is the administrator bind DN, see LDAP Bind DN and Password Change for more details.

      As you can only enter one user name and password, this user must be able to search all LDAP directory servers listed in the URL field.

      If the directory server supports anonymous binds, you can omit the user name and password. You must be able to perform LDAP queries for user data to use anonymous binds.

5. On the Review Selections step, check the authentication configuration and click Finish.

   If you enabled the LDAP search method, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Using Service Objects for more details.

SGD Administrators and Third-Party Authentication

By default, third-party authentication does not permit SGD Administrators to log in to SGD. This is a security measure. To change this behavior, use the following command:

$ tarantella config edit \
--tarantella-config-login-thirdparty-allowadmins 1

Trusted Users and Third-Party Authentication

Third-party authentication gives users access to SGD without having to authenticate to an SGD server. SGD is able to trust the third-party authentication mechanism because client applications, such as the webtop, and the SGD server have a shared secret which is the user name and password of a trusted user.

In a standard installation, there is just one trusted user. However, you might want to create additional trusted users in the following circumstances:

• You relocate the webtop to a different JavaServer Pages (JSP) technology container on a different host.

• You develop your own client applications, using the SGD com.tarantella.tta.webservices.client.views package, either on the same host as SGD or on a different host.

• You have concerns about the security of the default trusted user.

You create and maintain the “database” of trusted users on each SGD server in the array. The database is not shared between SGD servers. See How to Create a New Trusted User for details of how to add a trusted user. Note the following:

• The tarantella webserver add_trusted_user command is the only supported way to store trusted users on the SGD server.

• To change the password of an existing trusted user, you must first delete the user with the tarantella webserver delete_trusted_user command and then create the user again.

• Every time you make a change to a trusted user, you must restart the SGD web server.

• Usually client applications only use the credentials of a single trusted user to access SGD services.

Information for Application Developers

If you are using SGD web services to develop your own applications, the ITarantellaExternalAuth web service is used for third-party authentication. This web service is protected with Basic web server authentication so that you can only access it using the credentials of a trusted user. This is configured as follows:

• The http://SGD-server/axis/services/document/externalauth URL is protected in the configuration file for the Axis web application /opt/tarantella/webserver/tomcat/tomcat-version/webapps/axis/WEB-INF/web.xml

• The Tomcat component of the SGD web server is configured to support Basic web server authentication using Tomcat’s MemoryRealm and Secure Hash Algorithm (SHA) digested passwords. This is in the Tomcat configuration file /opt/tarantella/webserver/tomcat/tomcat-version/conf/server.xml.

• The list of trusted users is stored in the Tomcat users configuration file /opt/tarantella/webserver/tomcat/tomcat-version/conf/tomcat-users.xml

If you have developed your own client applications using the com.tarantella.tta.webservices.client.views package, you can store the trusted user credentials for the application in the same way as the webtop, see How to Create a New Trusted User. Otherwise, you need to develop your own methods for storing the credentials.

How to Create a New Trusted User

Before You Begin

Repeat the following procedure on each SGD server in the array.

1. Log in as superuser (root) on the SGD host.

2. Stop the SGD web server.

3. Add the new trusted user to the database of trusted users on the SGD server.

   1. Think of a user name and password for the trusted user.

   2. Create the trusted user.

      Use the following command:

      # tarantella webserver add_trusted_user username

      When prompted, type the password.

   3. Check the user is created.

      Use the following command:

      # tarantella webserver list_trusted_users

   4. Check that the trusted user works.

      Go to the http://SGD-server/axis/services/document/externalauth URL. When prompted, log in as the trusted user.

4. Add the new trusted user to the web services resources file for the webtop application.

   If you have relocated the webtop to a different host, perform this step on the remote host.

   1. Encode the user name and password of the trusted user.

      Use the following command:

      # /opt/tarantella/bin/jre/bin/java -classpath \
      /opt/tarantella/webserver/tomcat/tomcat-version/webapps/sgd/WEB-INF/lib/ sgd-webservices.jar \
      com.tarantella.tta.webservices.client.views.SgdPasswd \
      --encode username:password

   2. Copy the encoded user name and password from the output.

   3. Change to the shared resources directory.

      # cd /opt/tarantella/webserver/tomcat/tomcat-version
      # cd shared/classes/com/tarantella/tta/webservices/client/views

   4. Edit the Resources.properties file.

   5. Replace the text after sgdaccess= with the encoded user name and password.

   6. Save the changes.

5. Start the SGD web server.