Background

Security often plays a role in interacting with various external systems, protocols, and implementations. Security may take the form of authorization, authentication, or encryption. This initiative seeks to provide a common mechanism for components that need to handle authorization and authentication through the use of user names and passwords.

Requirement

• Passwords must be encrypted at all times. Clear-text passwords must never be made available to the end user
  • NOTE: A user may make use of other recommended features to fulfill this requirement. For example, passwords can be stored in the WSDL. They will likely be un-encrypted in the WSDL, but if the user makes use of environment variables, then the password will not be stored in the WSDL. To provide encryption capabilities in the tooling requires undesired coupling between tooling and runtime...something that is highly discouraged especially given the other solutions.
• It is preferred that the encryption methodology be selectable by the user.
• Passwords should be handled in a manner that is consistent with existing technologies (i.e. don't create an approach that is so radically different from technologies that you're using like the Glassfish Application Server or the Java SDK)
• Passwords must be changeable without having to redeploy the entire application.

Approach

Several functional areas need to be considered in providing a consistent password handling framework

1. Presentation
   1. Command-line interface
      • In an interactive form, the password must be masked and the user must be prompted at least once to confirm.
      • In a script form, the password must be stored in an encrypted format (like a password file) so that the password will not be in clear-text
   2. GUI interface
      • The password must be masked and the user must be prompted at least once to confirm
2. Persistence
   1. We will not mandate a single format for persistence of passwords
   2. Passwords must be encrypted when persisted.
   3. The user should be able to set the mechanism by which passwords are encrypted
   4. Detailed approach
      1. Provide a common class that all components can use which hides location of password storage. This common class will store passwords in glassfish storage, other properties local to the component. Components must use this class to store configuration
3. Runtime use
   1. Passwords will need to be changeable without having to redeploy the entire application.

Risks

• Often times, we have maintained a separation between tooling and runtime components for OpenESB components. Keeping this architectural principle in mind makes it harder to create a seamless password experience as the user moves from tooling to runtime. Any design will have to accommodate how these two sides will interact.
• For Java CAPS components, passwords are currently embedded as part of the application using very weak password obfuscation. With the number of legacy components, there are great risks in not being able to provide the consistent password experience without breaking backwards-compatibility.

This page (revision-1) was last changed on 29-Oct-07 16:23 PM, -0700 by Alexander.Fung.

More info...