WebSEAL junctions
The purpose of authenticating to WebSEAL is to access its protected resources, although WebSEAL provides minimum Web server functionality most commonly the resources protected will be on backend servers. WebSEAL's connections with the back-end Web servers have constantly been referred to as junctions. All WebSEAL junctions are connections between a front-end WebSEAL server and a back-end Web server which may be another WebSEAL server and may go via another proxy server. Only the HTTP and HTTPS protocols are supported and WebSEAL to WebSEAL connections must have SSL enabled.
A junction is where the back-end server Web space is connected to the WebSEAL server at a specially designated mount point in the Access Manager Web space created in the Policy Server database by appropriate use of the pdadmin command.
The junction is then a logical Web object space, normally on another Web server, rather than the physical file and directory structure of the proxied Web server. Junctions define an object space that reflects organizational structure rather than the physical machine and directory structure commonly encountered on standard Web servers. A browser client never knows the physical location of a Web resource as WebSEAL translates the requested URL addresses into the addresses that a back-end server expects without ever exposing them to the client. Web objects can be moved from server to server without affecting the way the client accesses those objects.
WebSEAL attempts to pass the request to the back-end server by referencing the object in Access Manager's protected object space. If it encounters an ACL or Policy of Protection, POP on that object which requires authentication before the request can be authorized, then the client will be challenged. WebSEAL is configurable for several different challenge mechanism including the default of Basic Authentication, forms based logon from a junctioned application and comes with an Application Developers Kit with which to build customized Cross Domain Authentication Services.
WebSEAL junctions can also be configured to enable the creation of Single Sign-On solutions allowing users to access resources, somewhat regardless of what security domain controls those resources, following their initial authentication logging on to through WebSEAL. The Global Sign-On (GSO) junction option allows for a third-party user registry to be referenced to supply that junction with the appropriate user ID and password. Other options involve manipulation and perhaps additions to the underlying Access Manager schema of inetOrgPerson, as each junction can be configured to supply all and any attributes from the schema through to the back-end server. If the logon identity and passwords from the user registries of several legacy applications can be migrated into extra attributes then those applications can be accessed through WebSEAL using only one initial login. Any further login requirements from back-end servers are handled as transparent to the user.
There are also Cross Domain Single Sign-On and e-Community Single Sign-On solutions. These solutions allow for the transfer of Access Manager user credentials across multiple security domains. Reference the Tivoli documentation.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.