Secure Global Desktop Administration Guide > Users and authentication > Web server/third party authentication
Web server/third party authentication allows users to log in to Secure Global Desktop if they have been authenticated by an external mechanism, such as web server authentication.
If you are using either the classic or browser-based webtop, you can only use web server authentication with these webtops. If you develop your own webtop applications using the Secure Global Desktop web services, you can use any external/third party authentication mechanism.
Web server authentication for the classic webtop is enabled by default.
Third party authentication for the browser-based webtop is disabled by default.
The user types in a username and password directly to the external mechanism, typically using their web browser's authentication dialog.
Web server/third party authentication is based on trust. Secure Global Desktop trusts that the web server/third party mechanism has authenticated the user correctly and so they are authenticated to Secure Global Desktop.
Once a user has been authenticated, Secure Global Desktop performs a search to establish the user's identity and login profile (see below).
To perform the search, one or more of the identity mapping search methods must be enabled on the Secure Global Desktop Login properties panel in Array Manager. The methods are tried in the order they are listed (see below).
If the searches do not produce a match, Secure Global Desktop can't establish an identity for the user and so the standard Secure Global Desktop login page displays. The user must log in to Secure Global Desktop so that a login authority can be tried.
Web server/third party authentication does not support ambiguous users and so the first match found is used.
Searches ENS for a person object with a Name, Username or Email Address attribute that matches the user's web/third party username.
The matching person object in ENS.
The matching person object in ENS.
Searches the LDAP directory for a person object with a cn (common name) attribute that matches the user's web/third party username. If there's no match, the search is repeated on the uid (username) attribute, and finally on the mail (email address) attribute.
The identity is the LDAP person object and has the form
.../_service/sco/tta/ldapcache/LDAP-person.
The first match of the following is used:
cn=Indigo Jones,ou=Administration,o=Indigo Insurance is found, this login authority would search ENS for o=Indigo Insurance/ou=Administration/cn=Indigo Jones.cn=LDAP Profile, in the same OU as the LDAP person object. For example, o=Indigo Insurance/ou=Administration/cn=LDAP Profile.cn=LDAP Profile, in any parent OU for the LDAP person object. For example, o=Indigo Insurance/cn=LDAP Profile.o=Tarantella System Objects/cn=LDAP Profile.Searches the LDAP directory for a person object with a cn (common name) attribute that matches the user's web/third party username. If there's no match, the search is repeated on the uid (username) attribute, and finally on the mail (email address) attribute.
The identity is the LDAP person object and has the form
.../_service/sco/tta/ldapcache/LDAP-person.
The profile object o=Tarantella System Objects/cn=LDAP Profile is always used for the login profile.
No search is performed.
For classic web server authentication, the user's identity is always .../_service/sco/tta/webauth/web-username.
For third party authentication, the user's identity is always .../_service/sco/tta/thirdparty/thirdparty-username.
For classic web server authentication, the profile object
o=Tarantella System Objects/cn=Web User Profile is always used for the login profile.
For third party authentication, the profile object
o=Tarantella System Objects/cn=Third Party Profile is always used for the login profile.
Emulator sessions and password cache entries belong to the identity established by the identity mapping search methods.
Copyright © 1997-2005 Sun Microsystems, Inc. All rights reserved.