WebClient caches each user ID and password entered by the end user and retrieves cached authentication information to access additional objects that require the same authentication. When the end user provides authentication information to connect to a server and to download files, WebClient can cache the authentication information and make it available to the application. Similarly, when the end user provides authentication information at an application prompt to connect to a server that contains business logic, the application can make the authentication information available to WebClient. By default, WebClient maintains a separate security cache for the application-configuration-file server and the codebase server.
Security caching lets you implement single sign-on, which keeps end users from being prompted multiple times for the same authentication information. Single sign-on is useful when:
Connecting to the same server multiple times during one session or across multiple sessions; for instance, when the same AppServer handles both downloads of application components and running business logic for the application. For example, if WebClient downloads application components before the application accesses the business logic, the the application can automatically connect to the AppServer to access the business logic using the same authentication information. Similarly, if the application accesses the business logic before WebClient downloads application components, the application can make authentication information available to WebClient when it connects to the AppServer to download application components.
Connecting to multiple servers that use the same authentication information. Suppose the application configuration file and the application components are on different servers, but you set the same authentication information for both servers. You can direct WebClient to make the configuration file's authentication information available to the application as codebase authorization information (but not the other way around).
Note: Authentication information is always stored encrypted.
Sharing the configuration file cache with the codebase cache works only if the application is launched from a shortcut, not from a Web browser—because in the latter case, the configuration file is downloaded by the Web browser, whose cache WebClient cannot access.
By default, WebClient does not maintain security caches on a particular machine across sessions. To override this default behavior, the end user must specifically request the persistent cache.
You can tell WebClient to disable the persistent cache. If you do so, the end user does not have the option of saving authentication information across sessions, and WebClient deletes the security caches at the end of each WebClient session.
Note: If persistent caching is not disabled, an end user can choose to persistently cache their authentication information for particular servers. After that, anyone starting a new WebClient session at the same machine and logging in as the original end user can access those servers without having to re-enter the authentication information.
Connecting to the same server multiple times during one session or across multiple sessions; for instance, when the same AppServer handles both downloads of application components and running business logic for the application. For example, if WebClient downloads application components before the application accesses the business logic, the the application can automatically connect to the AppServer to access the business logic using the same authentication information. Similarly, if the application accesses the business logic before WebClient downloads application components, the application can make authentication information available to WebClient when it connects to the AppServer to download application components.
