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:
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.
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.
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.
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:
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.
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.
The Use Default Third-Party Identity method does not perform a search.
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 involves the following configuration steps:
(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.
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.
Enable a third–party authentication mechanism.
The most common authentication mechanism used with third–party authentication is web server authentication.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
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.
The LDAP Repository Details step only displays if an LDAP search method is selected in Step 3.
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.
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.
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.
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.
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
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.
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.
Repeat the following procedure on each SGD server in the array.
Use the following command:
# tarantella webserver add_trusted_user username
When prompted, type the password.
Use the following command:
# tarantella webserver list_trusted_users
Go to the http://SGD-server/axis/services/document/externalauth URL. When prompted, log in as the trusted user.
If you have relocated the webtop to a different host, perform this step on the remote host.
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
# cd /opt/tarantella/webserver/tomcat/tomcat-version # cd shared/classes/com/tarantella/tta/webservices/client/views