Environment
Situation
Question
Can I edit, remove or add to the list of predefined SSO enabled applications?
Resolution
Answer
The short answer to the question is no (you cannot change the predefined list as such), but technically the answer is yes, because you can completely govern which applications are SSO enabled. Only the applications that you publish at the container level are available to users. Since you determine which applications are SSO enabled, the predefined list for your organization is completely customized (i.e. you SSO enable and publish the applications you require, and the rest are not used but are available if the SSO administrator wants to add them).
Predefined application definition assist SSO administrators to create and centrally publish a script for their application. ActivIdentity maintains the list of predefined SSO enabled applications and typically add more application defintions with each new release of SecureLogin.
You can effectively remove all application definitions (except the ones the SSO administrator publishes at the container level in the Directory) by disabling the Add Application wizards. This means no user will EVER be prompted to add any applications other than those the SSO administrator has specifically enabled. You can also remove users ability to modify or view application definitions with SecureLogin preferences, further locking down the behavior of SecureLogin.
You should completely control the SSO environment by developing and testing application definitions. You use ConsoleOne in Novell Directory environments, MMC in Microsoft Directory environments, or SecureLogin Manager in all other environments to centrally publish the SSO enabled application scripts. All users who then run the app will automatically inherit the application you have published. This approach will mean your SSO project is successful and supportable.
In a Directory environment (e.g. ADS, eDirectory, Sun One) a typical SecureLogin project team would setup the SSO enabled applications in the following way:
- Select and customize the applicable predefined application definitions and test and publish them at the container level so the application is SSO enabled for all users in the organization. Users who don’t have the application installed won’t notice any difference because they never run the application.
- Use the wizard and develop/customize scripts for applications that aren’t in the predefined list, and publish them at the container level so the application is SSO enabled for all users in the container (or use GPO in Microsoft environment). Users that don’t have the application installed won’t notice any difference because they never run the application.
- At the container level, set the option to prevent users from having access to view and modify application definitions so users are not able to SSO enable their own applications.
- At the container level, set the option to disable the add application prompts. This means SecureLogin won’t prompt the user to add an application when one that isn’t enabled is started.